Jump to content
IGNORED

Virtual ADAM high speed indexed Tape-Drive Computer Peripheral


Mr SQL

Recommended Posts

9 hours ago, Mr SQL said:

OK I think I narrowed it down to latency from this test build which is now very close to working on PlusCart -

 

This build now works fine in Stella and Harmony as well as UnoCart (which doesn't have the latency bug) and every corner works easily on the PlusCart except the upper right going into the TitleScreen for KC - this can freeze for 15 seconds (old SC bug triggered?) and reload the 1st load when it doesn't work.

 

The wrong supercharger ID appears to be cached at first? Maybe there is a delay for PlusCart functions before grabbing the ID from the "header" at the end of the load, if so storing it first would resolve.

 

Stella and Harmony (since there is no loading bar delay) can now be used to hold the button down, and you can see my delays between the transitions - plenty of time to see them even if you keep the button pressed the whole time so I think on the PlusCart the ID update needs to happen faster (or first before any PlusCart calls are made) once the load is running; it can't wait 2 seconds to update it or the transition usually breaks and hits the 15 second timeout and grabs the wrong load.

 

BREAKOUT_GUI_OS_hotfix5.bin 33 kB · 1 download

Tried your new build, but had still timeouts (lower left). As already said, when the timeouts occure there is no load attempt from the PlusCart. And after the timeout it is continuing with the load that is already in memory..
btw. I don't even know where the timeout happens (SC-Bios stub?)

I have starred for hours on the code but can not spot the bug in the difference between the UnoCart and PlusCart code:

PlusCart: https://gitlab.com/firmaplus/atari-2600-pluscart/-/blob/master/source/STM32firmware/PlusCart/Src/cartridge_emulation_ar.c

UnoCart: https://github.com/DirtyHairy/UnoCart-2600/blob/master/source/STM32firmware/Atari2600Cart/src/cartridge_supercharger.c

 

 

Edited by Al_Nafuur
  • Like 1
Link to comment
Share on other sites

6 hours ago, Al_Nafuur said:

Tried your new build, but had still timeouts (lower left). As already said, when the timeouts occure there is no load attempt from the PlusCart. And after the timeout it is continuing with the load that is already in memory..
btw. I don't even know where the timeout happens (SC-Bios stub?)

I have starred for hours on the code but can not spot the bug in the difference between the UnoCart and PlusCart code:

PlusCart: https://gitlab.com/firmaplus/atari-2600-pluscart/-/blob/master/source/STM32firmware/PlusCart/Src/cartridge_emulation_ar.c

UnoCart: https://github.com/DirtyHairy/UnoCart-2600/blob/master/source/STM32firmware/Atari2600Cart/src/cartridge_supercharger.c

 

 

Are you sure it is the load in the lower left that is timing out?

That one always works for me on the plus cart (I am light fingered, you have to be to beat the game it brings up).


I can make all the loads work on the BETA on the plus cart, including the upper right but that is the hardest -

 

I can make the load in the upper right work on the plus cart, but it is very hard to do consistently - I have to immediately let go of the button as soon as it transitions without waiting an extra frame. When I am able to do that it always enters the KC Title screen load. It's much easier to get from there to KC, and from KC back to BREAKOUT.

 

Something interesting to observe that may flush where the bug is -

 

Try holding the button extra time in Stella on the upper right or just keep it pressed down, and you will see it enter the title screen and there will be a ~1/2 second delay (20-30 frames) before it allows the button press to transition it to KC, and if you just keep it pressed down there will be another small delay before it will transition back to BREAKOUT.

 

Stella and Harmony transition immediately so may have needed to have a handler added - Uno and Plus do not transition right away because of the delay from the bars:

 

So I am thinking that maybe Dirty Hairy already grabbed the index from the footer at the end of the file when his loading bars start or during, while your code is waiting until they are finished to do this and so can encounter a race condition? 

 

There must be something different - I will stare at the code too and see if there is anything that jumps out at me :) 

 

Link to comment
Share on other sites

  • 2 weeks later...
On 9/4/2020 at 1:58 PM, Al_Nafuur said:

SuperChargerBIOS_Reflection_Idea.thumb.JPG.bea7dfdee2a6e3fad54a79dd852fd753.JPG

 

OK I took a look and have some ideas! :)  Here is the PlusCart code alongside Dirty Hairy's which is working perfectly on all multiloads. 

 

I think I see the following bug on the PlusCart side:

 

Dirty Hairy creates an instance called header based on the class above it when he sets up the map in static void setup_multiload_map, then he seeds this instance's attribute.

 

I think you are doing something different - you have instantiated an instance of an attribute of the class rather than the whole class and then refer to this instance attribute which I think is illegal and you get the old instance of the map sticking on subsequent loads.

 

Link to comment
Share on other sites

Every 8448 bytes load sequence of a supercharger file has a multiload_id (the 5th byte in the header). The function setup_multiload_map is to fill the multiload_map array (uint8_t [256]).

 

@DirtyHairy is loading the whole multiload header from the SD card and uses the 5th byte as id for the array and assigns it the sequence number of the load as value. This seems a little bit odd, but it is very clever, because the ROM is sending the multiload_id of the load it wants to be loaded next and not the sequence number. To find the sequence number of the load that is requested it just has to be looked up in the multiload_map array.

 

I am not requesting the whole multiload header over the internet in my setup_multiload_map function. I am just requesting the 5th byte of the header and assign it to a local uint8_t variable multiload_id (which is not related to the LoadHeader struct member multiload_id) and use this variable as id for the sequence number assignment.

 

Link to comment
Share on other sites

11 hours ago, Al_Nafuur said:

Every 8448 bytes load sequence of a supercharger file has a multiload_id (the 5th byte in the header). The function setup_multiload_map is to fill the multiload_map array (uint8_t [256]).

 

@DirtyHairy is loading the whole multiload header from the SD card and uses the 5th byte as id for the array and assigns it the sequence number of the load as value. This seems a little bit odd, but it is very clever, because the ROM is sending the multiload_id of the load it wants to be loaded next and not the sequence number. To find the sequence number of the load that is requested it just has to be looked up in the multiload_map array.

Why do you have 8448-251 instead of 8448-256 calculating the start address? Is this the offset for parsing the byte in the header??

This may account for why sometimes the wrong ROM is loaded or an incorrect value and the 15 second freeze occurs resetting to the 1st ROM in the multiload?

11 hours ago, Al_Nafuur said:

I am not requesting the whole multiload header over the internet in my setup_multiload_map function. I am just requesting the 5th byte of the header and assign it to a local uint8_t variable multiload_id (which is not related to the LoadHeader struct member multiload_id) and use this variable as id for the sequence number assignment.

I think you should request the whole 8 bytes in the header to make sure the start address is correct and the number of blocks being retrieved to support partial loads and loads where the start address and bank are different (not all start at the same address in bank 3/1 config).

 

Dirty Hairy's method is working very well, it's difficult to parse single bytes in a sparse header without breaking the header, header already sparse at 8 bytes so if parsing the header is not working it may be better to grab all 8 bytes. This will also enable the partial loads - I want to implement partial loads in SuperCharger BASIC and will test this next once we get the header working for multiloads :) 

 

Link to comment
Share on other sites

I think I made some progress with this - found a bug in SuperCharger BASIC that may be related:

 

#bugfix   20200919 2nd rem bug - 2nd rem causes code between to compile: rem e=SUPERCHARGERINDEX*50:COLUBK=e:rem debug
 

I removed a bad line from the programs that was passing bad index values on some of the loads.

 

I now have a stable SuperCharger OS demo for the SillyVenture compo that allows exit and controlled re-entry to two games and a third with no re-entry to the OS.

 

I still have to double check recursive loading but bidirectional loads and duplicate reference callbacks from the individual loads in the demo all worked perfectly on the PlusCart with this build :) 

 

I will post this shortly on it's own thread with some related ideas for keeping the demo as an online exclusive for PlusCart players until the official SillyVenture release in December! :) 

 

  • Like 1
Link to comment
Share on other sites

  • 2 months later...

Disk BASIC Development Update:

---------------------------------------

The SuperCharger Disk BASIC load command is fully implemented with optional arguments and overloading, here are a few examples in this code fragment and comments from my KC OS 12 SillyVenture 2020 demo which is available on preview in PlusCart exclusives, showing the different syntax possible:

1726955043_SuperChargerDiskBASICloadcommandexamples.thumb.JPG.a92d4ac0fb661825825cf6a9218e7dfb.JPG

 

Reasoning on overloading support and version history:

 

Simplification - BASIC should be easy so I simplified the command so that it could take an overload argument, but kept support for the previous method:

 

Specifying SUPERCHARGERINDEX is now optional, and a literal or variable argument (or the default) dynamically overloads the command.

 

Related ideas for discussion on language design - 

 

I think it's imperative for BASIC to have a PRINT command and commands are really just interfaces, intrinsic API's. 

Here is a nice WYSIWYG example from the manual displayed on the PlusCart text screen, and executing side by side:

print_command_example.thumb.JPG.59f3a14c8397b16538819e8aa48ee705.JPGprint_command_example_with_print@.thumb.JPG.b7bea62ab20f1aeab4c50aace5ce70d8.JPG

 

You can see how the proportional font illustrates the bitmap graphics from printing the binary strings on screen matching

what is seen on the sprite.

 

In the second example, the text is also printed on the playfield or the larger virtual world using BASIC print@ command style positioning!

 

Fun with languages, interfaces and intrinsic API's

----------------------------------------------------------

These print commands are additional interfaces on the same language intrinsic API's for manipulating BASIC RAM arrays -

 

Alternate BASIC array syntax supported and also write and print commands (from the manual):

 

write [alias: print]
------------------------
120 print %11111111(player0,0):rem print to top row of player 1 sprite.
130 write i(boats,j):rem write value i into boats array at element j.
140 boats(j)=5:rem standard BASIC array syntax is also supported
150 boats(j)=boats(x)*5:rem BASIC array manipulation

read 
---------------------
110 read i(boats,j):rem read element j from boats array into i.
120 i=boats(j):rem read element j from boats array into i.
130 boats(i)=boats(j): rem assign one array element variable to another. 

 

For discussion - why have multiple commands and interfaces to the same language intrinsic? 

Wouldn't it be more efficient to have one best way?

 

Why support overloading with the load command?

"Programmers might learn more about programming without overloading" is a good argument against,

 "that's what computers are for" is a good argument for.

 

Ditto for multiple commands and interfaces.

 

These are some of the things that the designers of programming languages think about, share your thoughts if you want to talk about these ideas! I'm trying to add support for loading sectors or just one bank but seeing forced corruption on the last block? 

 

I encourage @Andrew Davie, @Thomas Jentzsch and @alex_79 to have a high level programming discussion on this private forum and please do not throw insults, encourage others to throw insults or constantly follow me about angry making demands of other programmers when I talk technology with them on the public forums - 

 

If you want to play a game, get on the gamegrid with me like @sramirez2008 and let's play Atari! :) 

WorldsMostInterestingManNolanBushnell.thumb.jpg.3a7d1b9a704c2462da5b56b03b2784ca.jpg

 

@Al_Nafuur Possible text-viewer line length bug: the second example breaks in the text viewer, but is not using any additional characters than the 1st.

 

  • Like 1
Link to comment
Share on other sites

6 hours ago, Mr SQL said:

Related ideas for discussion on language design - 

 

I think it's imperative for BASIC to have a PRINT command and commands are really just interfaces, intrinsic API's. 

 

 

Are you planning to support PlusROM functions in your SuperCharger BASIC too?

 

  • Like 1
Link to comment
Share on other sites

3 hours ago, Al_Nafuur said:

Are you planning to support PlusROM functions in your SuperCharger BASIC too?

 

Yes! :)  I am going to start on this next for Atari Flashback BASIC, which is cross compatible with SuperCharger BASIC but uses CBS RAM which already has PlusROM function support.

 

I could back-port it to SuperCharger BASIC and release them together if we are able to add SuperCharger support before June 21.

 

New dev Idea inspired from an unintended error other thread:

I would like to add the DOS load command to Flashback BASIC using the PlusROM API's in place of the SuperCharger BIOS -

Theoretically this would allow the same set of BASIC programs to run and call one another with no changes to the code.

 

Minor abstraction differences would be that the individual programs would have no security to prevent them from being called individually* like the SuperCharger BIOS imparts, advantages would be that any size Atari program and memory scheme could be loaded by Flashback BASIC.  

 

*Programs could be run individually on the Flashback Portable for backward compatibility; I'll need to double test this while adding this enhancement because the Portable emu has some quirks like formatting CBS RAM like disk sectors from bitd (all $FF instead of $00) and it doesn't like blank space, requires adding filler to banks.

 

8 hours ago, Al_Nafuur said:

the text-viewer has a maximum length of 1024 rows with 32 chars..

The lines are more than 32 characters long in the 2nd example.

I had thought I saw a word-wrap feature for long lines, maybe having more than 32 characters with no spaces is breaking it?

 

Link to comment
Share on other sites

2 hours ago, Mr SQL said:

The lines are more than 32 characters long in the 2nd example.

I had thought I saw a word-wrap feature for long lines, maybe having more than 32 characters with no spaces is breaking it?

 

The PHP wordwrap function (with cut parameter set to TRUE) is used at the PlusStore API for transforming the textfiles to "pseudo" directories for the PlusCart.

 

Link to comment
Share on other sites

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...