Jump to content
IGNORED

AtariMax 8Mbit Flash cart with SDX 4.49c and all OSS languages


ebiguy

Recommended Posts

On 4/14/2020 at 9:08 AM, _The Doctor__ said:

time for a 4.49 final version

This time, here it is.

 

This packaging is exactly the same as the previous ones based on 4.49c.

So you can either read the readme file embedded in the zip or browse this thread for information.

But you need to be aware of 2 important differences:

- The MAC/65 cartridge is no longer inserted at boot time.
  The cartridge starts empty and you must issue a 3-letter command (like M65 for MAC/65) to virtually insert the cartridge.

  I did not take the time to investigate why but I guess this behavior comes from a difference between SDX 4.49c and 4.49.
- The OSS bankswitching emulation has been rewritten. It does not use the stack anymore for the bankswitching code.
  With this modification, the system should be more reliable than with the previous published packages.
  But it means that the BASICX8.OSS file has been updated to match the new bankswiting code.
  In order to use Basic XE extension, you must use the version included in this package and NOT the one from the previous packages!
  Failing to do that will crash Basic XE when loading its extensions

 

I did not test extensively everything but I tried some languages and used both packages in Altirra emulating an MaxFlash 8Mbit cartridge and The!Cart cartridge.

So far, it seems to work.

 

Have fun and report any issues.

My8MbitFlash_SDX449_OSS_v7.zip

Edited by ebiguy
  • Like 3
Link to comment
Share on other sites

4 hours ago, ebiguy said:

This time, here it is.

 

This packaging is exactly the same as the previous ones based on 4.49c.

So you can either read the readme file embedded in the zip or browse this thread for information.

But you need to be aware of 2 important differences:

- The MAC/65 cartridge is no longer inserted at boot time.
  The cartridge starts empty and you must issue a 3-letter command (like M65 for MAC/65) to virtually insert the cartridge.

  I did not take the time to investigate why but I guess this behavior comes from a difference between SDX 4.49c and 4.49.
- The OSS bankswitching emulation has been rewritten. It does not use the stack anymore for the bankswitching code.
  With this modification, the system should be more reliable than with the previous published packages.
  But it means that the BASICX8.OSS file has been updated to match the new bankswiting code.
  In order to use Basic XE extension, you must use the version included in this package and NOT the one from the previous packages!
  Failing to do that will crash Basic XE when loading its extensions

 

I did not test extensively everything but I tried some languages and used both packages in Altirra emulating an MaxFlash 8Mbit cartridge and The!Cart cartridge.

So far, it seems to work.

 

Have fun and report any issues.

My8MbitFlash_SDX449_OSS_v7.zip 1.11 MB · 12 downloads

When using the default image with the Romdisk I have the following issues

 

If I type

INT

CAR

DOS

ACT

CAR

then Altirra crashes if I try to type in an Action! program

 

If I type

BXE

CAR

DOS

BXL

CAR

here I get the the cassette PRESS RETURN tone. The first tone lasts for about 3 seconds. After this it repeats constantly at about twice per second.

 

-SteveS

  • Thanks 1
Link to comment
Share on other sites

6 hours ago, a8isa1 said:

When using the default image with the Romdisk I have the following issues

Thank you so much for testing.

You are really good at QA.

These 2 languages (Action! and BasicXE) were not working fine.

Now it's fixed and, again, the file BASICX8.OSS has been changed.

Could you try again please?

My8MbitFlash_SDX449_OSS_v8.zip

Link to comment
Share on other sites

1 hour ago, flashjazzcat said:

Have any of the SDX 4.49 changes impacted the SIDE OSS cart builds to your knowledge

I would say no but not 100% sure as I do not master the SDX boot process.

The important change I noticed (which impacts my menu when booting with START) is that SDX now initializes at a different stage ($04 instead of $01 at $BFFD).

But I don't know if it could impact the SYSTEM RESET behavior.

 

Edited by ebiguy
Link to comment
Share on other sites

2 minutes ago, ebiguy said:

I would say no but not 100% sure as I do not master SDX the boot process.

The important change I noticed (which impacts my menu when booting with START) is that SDX now initializes at a different stage ($04 instead of $01 at $BFFD).

But I don't know if it could impact the SYSTEM RESET behavior.

OK. I think I will just release everything as it is and we can clean up any problems after the event. Otherwise the new firmware will still be waiting by Christmas. :)

 

  • Like 1
Link to comment
Share on other sites

The car handling at boot was changed in 4.49final

External cartridge will now be initialized and run at SDX startup only when OPTION+ESC is depressed.
-The proper way to run a cartridge is now to wait for the SDX startup, then use the CAR command at
the command prompt.

how most carts worked previously they would initialize and then sparta would go from there.

sparta now goes and the then inits the external cart with the CAR command and in it goes. This makes sure Sparta is fully in control, as soon as I am fully back on my feet, I'll see how it works with the dual tower of power (as video demonstrated in some old thread on AA). At the time we had to hot plug a cart and this change may negate the need to do so. If it breaks anything option+esc should get us around it... but option is used as bypass on some multi/flash/emu carts... testing testing testing... a8 is a1 @a8isa1 will you check this out across the cart spectrum that you may have?

Link to comment
Share on other sites

4 hours ago, _The Doctor__ said:

The car handling at boot was changed in 4.49final


External cartridge will now be initialized and run at SDX startup only when OPTION+ESC is depressed.
-The proper way to run a cartridge is now to wait for the SDX startup, then use the CAR command at
the command prompt.

how most carts worked previously they would initialize and then sparta would go from there.

sparta now goes and the then inits the external cart with the CAR command and in it goes. This makes sure Sparta is fully in control, as soon as I am fully back on my feet, I'll see how it works with the dual tower of power (as video demonstrated in some old thread on AA). At the time we had to hot plug a cart and this change may negate the need to do so. If it breaks anything option+esc should get us around it... but option is used as bypass on some multi/flash/emu carts... testing testing testing... a8 is a1 @a8isa1 will you check this out across the cart spectrum that you may have?

I only have ebiguy's composed build.  I have no hardware to test true external carts.  I had wondered if SDX 4.49 final's handling of cartridge initialization might affect the composition's behavior.

Link to comment
Share on other sites

7 hours ago, ebiguy said:

Sorry to spam this thread with different packaging versions but I found why the MAC/65 was not inserted on startup as it should be.

Nothing related to SDX 4.49 but a stupid bug on my side.

Hope this is the last upload!

My8MbitFlash_SDX449_OSS_v9.zip 1.11 MB · 8 downloads

This is a little different.

 

In Altirra I get the same behavior in Action! as I did before.  If I try to type a program the emulation crashes.

 

However, in atari800 emulator I can type a program and compile the same.

 

More detail to an earlier problem.

 

- BXE, CAR, DOS followed by selectign any cartridge triggers the cassette tone issue.   Tones play after CAR is typed.  This is the same issue I mentioned in my earlier post but I now know that BXE triggers it.

 

The following I've only tried in atari800 emulator (4.1)

 

Each of the below after clean boot:

 

- Action! seems to work

- MAC/65 seems to work.  Just a one line program and compilation test.

- Synassembler the same

- BXL works

- ATB works

- Pilot starts but I don't know this language/environment so I can't create a program.  Typing DOS returns to the SDX command line but the cursor is not visible.

 

Running BXL first and then Action! causes Action! program to misbehave

 

Sample program below generates no output and doesn't return control back to the Action! monitor.  Emulation is not frozen however.  Program compiled without errors

 

PROC MAIN()

BYTE VALUE=[0]

PRINTBE(VALUE)

 

The program works fine if BXL is not used before Action!.

 

-SteveS

Link to comment
Share on other sites

I can not reproduce.

With the latest version, in Altirra 3.20, I can type BXE, DOS, BXL, DOS, M65, DOS, ACT and type the program without any problem and compile it.

I will need more information.

Could you describe your Altirra configuration (hardware, memory,...) and version of Altirra?

When running Basic XE, are you loading the extensions?

Link to comment
Share on other sites

32 minutes ago, ebiguy said:

I can not reproduce.

With the latest version, in Altirra 3.20, I can type BXE, DOS, BXL, DOS, M65, DOS, ACT and type the program without any problem and compile it.

I will need more information.

Could you describe your Altirra configuration (hardware, memory,...) and version of Altirra?

When running Basic XE, are you loading the extensions?

This is getting stranger.

 

The problem only occurs when using Atari XL/XE OS and system configured with 128K of RAM.  Happens in both atari800 and Altirra Emulators.

 

Commands

BXE

CAR

DOS

BXL

CAR

<tones happen here>

 

p.s. I'm using Atirra-3.90-test27.   I don't have any other versions installed t present.

Edited by a8isa1
Link to comment
Share on other sites

11 minutes ago, a8isa1 said:

The problem only occurs when using Atari XL/XE OS and system configured with 128K of RAM.  Happens in both atari800 and Altirra Emulators.

Yes, and that is the expected behavior if you load the extensions

Here is my note from the first post in this thread:

Technical note 3: To use the Basic XE Extension, you need to run SDX in BANKED mode and have more than 128Kb so that SDX and Basic XE won't use the same memory banks.

With 128K, SDX uses one of the 4 banks but Basic XE also will use the same banks.

 

If you enter BXE without the extensions, then I don't know. Maybe Basic XE writes to a bank of memory. I did not check.

 

1) Are you loading the extensions?

2) Did you test on the real hardware also (which configuration)?

  • Like 1
Link to comment
Share on other sites

46 minutes ago, ebiguy said:

Yes, and that is the expected behavior if you load the extensions

Here is my note from the first post in this thread:

Technical note 3: To use the Basic XE Extension, you need to run SDX in BANKED mode and have more than 128Kb so that SDX and Basic XE won't use the same memory banks.

With 128K, SDX uses one of the 4 banks but Basic XE also will use the same banks.

 

If you enter BXE without the extensions, then I don't know. Maybe Basic XE writes to a bank of memory. I did not check.

 

1) Are you loading the extensions?

2) Did you test on the real hardware also (which configuration)?

not that I know.  I only used Basic XE, exited to SDX, and then tried to use BASIC XL (or any other cartridge)

 

The problem doesn't occur if I use Altirra Emulator OS.

 

I would not be able to duplicate the problem on my 800XL.   I have Rambo XL upgrade permanently installed.

 

-SteveS

Link to comment
Share on other sites

6 hours ago, a8isa1 said:

When I select ACT and type CAR I enter the Action! editor but I cannot type anything

Sorry but I can not reproduce.

ACT+CAR+type anything works in all my configurations: under Altirra (2.60, 3.20, 3.90test31) and in my 130XE U1MB in all memory config (128K, 320K, 576K, 1088K) with stock OS.

Are you sure you are using the lastest version I posted (My8MbitFlash_SDX449_OSS_v9.zip)?

 

Anyone else having the same issues?

Link to comment
Share on other sites

@phaeron

there is something I don't understand, if you could explain...

I was using for many years Altirra 2.60 for these packaged SDX (I started with SDX 4.46).

I never felt the need of upgrading Altirra as it was working well.

With the issues reported by a8isa1, I downloaded the official 3.20 and also the 3.90test31.

And then I got a different behavior with the SELECT key.

With 2.60, I can boot with SELECT held down and it boots in OSRAM config but not with 3.20 and 3.90.

When I try on real hardware (but with U1MB), the SELECT key is working as expected but I guess that U1MB changes the test conditions.

If you want to put a breakpoint in my code just after LDA CONSOL, it is located at $BFAB

If you have time for that, be sure to download the latest version (v9).

Does it mean that my code is the first to read CONSOL keys and it should be initialized before reading (LDA #8, STA CONSOL)?

EDIT: I forgot to say that the code at $BFAB is only reached if you have extended memory banks. It is skipped if you choose a stock 800XL for example.

Edited by ebiguy
Link to comment
Share on other sites

1 hour ago, ebiguy said:

@phaeron

there is something I don't understand, if you could explain...

I was using for many years Altirra 2.60 for these packaged SDX (I started with SDX 4.46).

I never felt the need of upgrading Altirra as it was working well.

With the issues reported by a8isa1, I downloaded the official 3.20 and also the 3.90test31.

And then I got a different behavior with the SELECT key.

With 2.60, I can boot with SELECT held down and it boots in OSRAM config but not with 3.20 and 3.90.

When I try on real hardware (but with U1MB), the SELECT key is working as expected but I guess that U1MB changes the test conditions.

If you want to put a breakpoint in my code just after LDA CONSOL, it is located at $BFAB

If you have time for that, be sure to download the latest version (v9).

Does it mean that my code is the first to read CONSOL keys and it should be initialized before reading (LDA #8, STA CONSOL)?

EDIT: I forgot to say that the code at $BFAB is only reached if you have extended memory banks. It is skipped if you choose a stock 800XL for example.

It is working for me, but I may be using a different test cartridge image than you.

 

Yes, you do need to ensure that CONSOL bits 0-2 are reset before attempting to read the console buttons, as the S0-S2 lines on the GTIA are bidirectional. Any 1 bits in the output half of CONSOL will pull down the corresponding switch line and cause it to read as 1 regardless of the state of the button, and there is no reset logic for the CONSOL output latches. Mid-way through the 3.20-test series I did checks on the real hardware with a diagnostic cartridge to tune Altirra's power-on state. On a stone cold boot, CONSOL is typically read back as $00 with no buttons pressed, which meant a state of $0F on the write side. A lukewarm boot can end up with any CONSOL value, but this is why you need to write $08 to ensure that the buttons are readable if you are running pre-OS-init at diagnostic cart init time. After that, the OS clears the hardware registers and reading the CONSOL switches should work as typically no one writes values other than $00 or $08 to it.

 

And yes, you can get different results with U1MB for any registers that are hit by the BIOS prior to the OS and cartridge booting. Flashjazzcat is meticulous about trying not to disturb machine state as much as possible from it, but there are some hardware registers that have to be hit for BIOS functions to work.

 

That having been said, if you are running this check as part of SDX boot, that's post-diagnostic, so CONSOL should already be initialized by the OS. I don't know what the timing is like in your case, but if it is quick, you can have the emulator hold down the button for you to ensure it is held in time after power-up (Alt+F1, F2, then reset).

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

5 hours ago, phaeron said:

you can have the emulator hold down the button for you to ensure it is held in time after power-up (Alt+F1, F2, then reset)

Thank you for your answer.

I did not know about the option to hold down the CONSOLE keys

Now I understand what is happening.

The way I did it was to launch the emulator and wait for SDX to finish booting and then I pressed F3 for SELECT. Keeping F3 pressed, I clicked on reset in the main menu.

This was working well in version 2.60 but not for 3.xx versions.

And maybe that's why you have added 'Hold Keys for Reset' for 3.xx version.

Link to comment
Share on other sites

13 hours ago, ebiguy said:

Sorry but I can not reproduce.

ACT+CAR+type anything works in all my configurations: under Altirra (2.60, 3.20, 3.90test31) and in my 130XE U1MB in all memory config (128K, 320K, 576K, 1088K) with stock OS.

Are you sure you are using the lastest version I posted (My8MbitFlash_SDX449_OSS_v9.zip)?

 

Anyone else having the same issues?

I believe I found the problem.  

 

I composed my own ATR for the Romdisk and concatenated the parts to form my cartridge image.

 

When I do the same with your Romdisk449.atr I get the same behavior trying to use the Action! cartridge.

 

I used this command (using linux)

 

cat first_part449.bin Romdisk449.atr last_part449.bin >  test.bin

 

Md5sums don't match

249995ad8ee9c8325e43e777514460a6  My8MbitFlash_SDX449_OSS_romdisk.bin

0c2238780a033e9bbbe6328b788c34cf  test.bin

 

 

  • Like 1
  • Sad 1
Link to comment
Share on other sites

43 minutes ago, a8isa1 said:

I believe I found the problem. 

Bravo !!!

And it means that something is wrong with one file in the delivery.

The bad file is first_part449.bin which I forgot to update in the previous delivery.

This shows that I should automate the zip file creation to avoid this kind of error.

So again, here is the full package.

 

My8MbitFlash_SDX449_OSS_v10.zip

 

@a8isa1, you don't need to customize again the Romdisk449.atr, you can go on with the one you already prepared.

This file has not changed.

Just get all others to be sure everything is consistent this time.

 

EDIT: I forgot one important thing: thank you for using this package and sorry for the time you spent investigating on this issue.

I am happy if you find this SDX setup useful!

Edited by ebiguy
  • Like 3
  • Thanks 1
Link to comment
Share on other sites

15 hours ago, ebiguy said:

Thank you for your answer.

I did not know about the option to hold down the CONSOLE keys

Now I understand what is happening.

The way I did it was to launch the emulator and wait for SDX to finish booting and then I pressed F3 for SELECT. Keeping F3 pressed, I clicked on reset in the main menu.

This was working well in version 2.60 but not for 3.xx versions.

And maybe that's why you have added 'Hold Keys for Reset' for 3.xx version.

Checked the history and the issue is a fix I made in 2.70 to force all keys up on focus loss to prevent stuck keys. This includes the F2-F4 console keys. So yeah, definitely use the auto-hold for testing.

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