Jump to content
Al_Nafuur

New release

Recommended Posts

7 minutes ago, Andrew Davie said:

I didn't write that...!

I wrote this ;-)

 

 

Edited by Al_Nafuur

Share this post


Link to post
Share on other sites
8 minutes ago, Andrew Davie said:

 

Looks to me like it would have to be doing that. The BRK vector is pointing to FirstStart.

 

so we just add 

      LDA	#0
      STA	SWCHA 
      STA	SWACNT
      STA	SWCHB
      STA	SWBCNT

to FirstStart ?

Share this post


Link to post
Share on other sites
5 minutes ago, Al_Nafuur said:

my proposal is to feed this exit sequence in the exit_cartridge function (instead of the just the NOP and BRK):

const uint8_t exit_sequence[] __attribute__((section(".flash01"))) = {
    0xea,                   //      NOP
    0xa9, 0x00,             //      LDA	#0
    0x8d, 0x80, 0x02,       //      STA	SWCHA 
    0x8d, 0x81, 0x02,       //      STA	SWACNT
    0x8d, 0x82, 0x02,       //      STA	SWCHB
    0x8d, 0x83, 0x02,       //      STA	SWBCNT
    00x0                    //      BRK
};

 

 

So first, there's a write to SWCHA, when the direction (input/output) is unknown. If set to input, I guess it has no effect.

But if set to output, then the write does *something* we know not what, because... what's connected to it?

The direction is only in a known state after write to SWACNT. Writing 0 to that sets the direction (DDR) to input.

So although I'm not familar with these registers, I would probably be swapping those two around. Set direction first.

And then, if you're setting it to read -- I'm unsure why you'd want to write to SWCHA anyway.

Next, port B (SWCHB) is hardwired to input. And the control register SWBCNT only got one mention in the stella manual, nothing about writing to it.

I can understand setting the direction of SWACNT to a known state (input). But I don't understand the SWCHB stuff, nor the need to write to SWCHA

Perhaps this is a '7800 thing???

 

Share this post


Link to post
Share on other sites
2 minutes ago, Andrew Davie said:

 

So first, there's a write to SWCHA, when the direction (input/output) is unknown. If set to input, I guess it has no effect.

But if set to output, then the write does *something* we know not what, because... what's connected to it?

The direction is only in a known state after write to SWACNT. Writing 0 to that sets the direction (DDR) to input.

So although I'm not familar with these registers, I would probably be swapping those two around. Set direction first.

And then, if you're setting it to read -- I'm unsure why you'd want to write to SWCHA anyway.

Next, port B (SWCHB) is hardwired to input. And the control register SWBCNT only got one mention in the stella manual, nothing about writing to it.

I can understand setting the direction of SWACNT to a known state (input). But I don't understand the SWCHB stuff, nor the need to write to SWCHA

Perhaps this is a '7800 thing???

 

then we just add 

      LDA	#0
      STA	SWACNT

to FirstStart ?

 

Share this post


Link to post
Share on other sites
Just now, Al_Nafuur said:

then we just add 

      LDA	#0
      STA	SWACNT

to FirstStart ?

 

Perhaps @alex_79 might comment on this, because I don't understand the need for the others.

Share this post


Link to post
Share on other sites
3 minutes ago, Andrew Davie said:

Perhaps @alex_79 might comment on this, because I don't understand the need for the others.

Yes, and maybe we should discuss this in this thread:

 

Share this post


Link to post
Share on other sites
2 hours ago, Al_Nafuur said:

No, the reset sequence requires to pull RIOT pin 34 (/RES) low:

R6532_datasheet.thumb.png.4796fc9dd4bfc470c1013a5ee0fc0875.png

 

On a 2600 this only happens when powering on the console.
E.g.: this is from the 6-switch console schematic:

CX2600-CX2600A_Official_schematics.thumb.png.112b95c84dc94340c8d98b98c6fb5634.png
After turning on the console, the /RES pin will initially be "low" until the capacitor (C220, charged through the resistor R217), will reach the voltage for a logic "1". Then it will just stay "high" as long as the console is powered on.

 

Share this post


Link to post
Share on other sites
1 hour ago, Andrew Davie said:

 

So first, there's a write to SWCHA, when the direction (input/output) is unknown. If set to input, I guess it has no effect.

But if set to output, then the write does *something* we know not what, because... what's connected to it?

The direction is only in a known state after write to SWACNT. Writing 0 to that sets the direction (DDR) to input.

You can write to SWCHA and SWCHB even if they're set as input and the RIOT "remembers" the value when you set them as output.

 

Quote

 

Next, port B (SWCHB) is hardwired to input. And the control register SWBCNT only got one mention in the stella manual, nothing about writing to it.

I can understand setting the direction of SWACNT to a known state (input). But I don't understand the SWCHB stuff, nor the need to write to SWCHA

Perhaps this is a '7800 thing???

 

That's one of those occurrences where the "Stella Programmer's Guide" describes the intended usage rather than the actual behaviour.
In the 2600, port B is connected to the console switches, so it was meant to be used as input only. But that's a standard 6532, and the port is fully configurable.

The 3 unused bits can be safely set as output and used as 3 bits of memory. "Combat" does that for example.

 

Technically, you can set also the other bits as output, and reading them will always return the programmed value and not the position of the switches, but it has not been determined if it's safe for the chip in case you set a bit "high" while the connected switch is closed, that means the pin is shorted to ground.
I remember this was discussed a few years ago in the forums.

 

Edited by alex_79

Share this post


Link to post
Share on other sites
1 minute ago, alex_79 said:


I remember this was discussed a few years ago in the forums.

 

This is exactly the sort of thing I started the Woodgrain Wizadry Tiki for!

I'll get some notes on this updated soon!

 

  • Like 1

Share this post


Link to post
Share on other sites

The point of the Tiki is not to compete with AA, but instead to collate and bring together all the latest and greatest information in an accessible way so that it's quiick to find and always up-to-date. I hope you feel like contributing!

 

  • Like 1

Share this post


Link to post
Share on other sites

New draft version v2.0.10

 

For draft User @Prizrak, @Andrew Davie, @Thomas Jentzsch, @Mr SQL and @Fierodoug5

 

  • update STM32CubeIDE to v1.6.0
  • reset RIOT at start and after exit emulation
  • exit input fields properly
  • more generic keyboard
  • clean up status messages
  • always escape spaces in API HTTP requests
  • Andrew Davie's fix for menu delays (init and joystick up/down)

some of the changes above are already included in v2.0.9

 

  • Like 1

Share this post


Link to post
Share on other sites

Missing the recent update to the keyboard(s) that includes a basic row of space/punctuation on the alpha keyboards.

That was a huge time-saver IMHO, and definitely worth merging ASAP.

 

  • Like 1

Share this post


Link to post
Share on other sites

BUG: This is losing my display preferences on a power-cycle.

In particular, my FONT is not correct on power off/on.

 

Share this post


Link to post
Share on other sites
1 hour ago, Andrew Davie said:

BUG: This is losing my display preferences on a power-cycle.

In particular, my FONT is not correct on power off/on.

 

Yes the whole User.Settings are set to default, but the correct values are stored..

🤔

Share this post


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

BUG: This is losing my display preferences on a power-cycle.

In particular, my FONT is not correct on power off/on.

 

should be fixed now with v2.0.11

Share this post


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

Missing the recent update to the keyboard(s) that includes a basic row of space/punctuation on the alpha keyboards.

That was a huge time-saver IMHO, and definitely worth merging ASAP.

 

added to v2.0.12

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

New public version v2.1.0 in PlusStore and GIT.

Changes since last public version v1.1.0:

 

  • Common Code base with UnoCart
  • Bugfix for loading SuperCharger ROMs from flash (Offline ROMs)
  • Bugfix for new keyboard adds slash to WiFi password
  • Bugfix for download of files smaller than 32 KiB to flash (Offline ROMs)
  • A basic row of space/punctuation on the alpha keyboards
  • Bugifx in eeprom addressing
  • Update STM32CubeIDE to v1.6.1
  • Reset RIOT at start and after exit emulation
  • Exit input fields properly
  • More generic keyboard
  • Clean up of status messages
  • Always escape spaces in API HTTP requests
  • @Andrew Davie's fix for menu/keyboard delays (init and joystick up/down)

 

 

  • Like 2
  • Thanks 2

Share this post


Link to post
Share on other sites

Hi, I like the new release, just have to download/detect offline ROMS each time on one of my PlusCarts. How to fix it? Offline roms always disappear with new start of PlusCart.

Share this post


Link to post
Share on other sites
1 hour ago, Wizzard said:

Hi, I like the new release, just have to download/detect offline ROMS each time on one of my PlusCarts. How to fix it? Offline roms always disappear with new start of PlusCart.

If "Offline ROMs" are available is stored in the User Settings in eeprom emulation area. Loosing this info might/should be the same issue than here:

 

Unfortunately there is no option to reset/format the eeprom user settings area in the menu, so this has to be done via the STM32CubeProgrammer

Share this post


Link to post
Share on other sites

Okay, so one of my PlusCarts will never detect my offline ROMs? How is it possible that I have offline roms available on another PlusCart? I upgraded the firmware on one day, one after another.

Edited by Wizzard

Share this post


Link to post
Share on other sites

  • Recently Browsing   1 member

×
×
  • Create New...