Missing features?

[+Al_Nafuur]

maybe one topic is not enough to discuss and prioritize all possible features. My suggestion is to open a new topic "Feature Requests" where every feature can be opened and discussed in a separate thread. And the prioritization will be a pinned voting..
I am not sure if this a good solution, but every other tool would be insufficient (like gitlab board, voting tools, trello,..) and would be public available or would need another login.

Does someone knows a better tool/solution?

 

I set up an trello board and pasted in all features:
https://trello.com/b/vcpDw4Qc/pluscart-feature-discussion-board

 

the board is public readable, all trello user can comment and vote, but only invited user can set up new features or move them.

Edited March 16, 2020 by Al_Nafuur

[Thomas Jentzsch]

Don't expect a lot of feedback. Most people are just consuming.

[+Al_Nafuur]

3 minutes ago, Thomas Jentzsch said:

Don't expect a lot of feedback. Most people are just consuming.

Then nobody can complain, if i implement features by my own priorization..
?

[Thomas Jentzsch]

We are mostly doing the same with Stella too.  

[+Al_Nafuur]

5 minutes ago, Thomas Jentzsch said:

We are mostly doing the same with Stella too.  

PlusROM functions would be a feature i would like for Stella, unfortunately my fork is 8 weeks and a zillion commits behind.. ? 

[Thomas Jentzsch]

Maybe create an issue it Github for it. After we have released 6.1, we will need new priorities for 6.2.

 

And get your fork updated regularly.

Edited March 16, 2020 by Thomas Jentzsch

[Dionoid]

On 3/1/2020 at 9:05 AM, Thomas Jentzsch said:

...

• And then we had a discussion about where to put the PlusROM data and code. Currently the PlusROM uses the first ~31 bytes of each bank. While this may be no major problem for new games, it makes converting existing games quite complicated. Because it will always shift the whole code. So you need a complete disassembly to get the addresses fixed. And even then this will frequently cause major problems to get it working again (BTW: SuperChip games!?). I like the feature and would like to see this added for more existing games. Therefore I suggested to either put this data towards the end of each bank, or to use a 2 bytes address (e.g. at the unused interrupt vector) which points at the data. This would make converting existing games much easier.

...

Using the interrupt vector to point to the backend API string is a great idea! 

 

Maybe, for existing games with only a small amount of free bytes, a predefined value in the interrupt vector (e.g. value $FFFF) could be interpreted by the PlusCart to use the hardcoded highscore API at highscore.firmaplus.de. That would save 31 bytes of ROM, which for existing games is a lot IMO.

Edited March 20, 2020 by Dionoid

[Thomas Jentzsch]

5 minutes ago, Dionoid said:

Maybe, for existing games with only a small amount of free bytes, a predefined value in the interrupt vector (e.g. value $FFFF) could be interpreted by the PlusCart to use the hardcoded highscore API at highscore.firmaplus.de. That would save 31 bytes of ROM, which for existing games is a lot IMO.

Good idea. ?

[+Al_Nafuur]

33 minutes ago, Dionoid said:

Maybe, for existing games with only a small amount of free bytes, a predefined value in the interrupt vector (e.g. value $FFFF) could be interpreted by the PlusCart to use the hardcoded highscore API at highscore.firmaplus.de. That would save 31 bytes of ROM, which for existing games is a lot IMO.

I don't like these kind of hacks and solutions that only work with one use case. Opening this feature to all developer means we have to implement and maintain a "PlusROM backend database" in ever PlusROM enabled device and emulator. But this would need a new release for all, if a new backend is added.

 

Another solution would be a free online register for PlusROMs where developer send in the md5 sum of their ROM and the domain and Path for the backend. But this means:

• more work for the developers
• the PlusROM enabled device has to compute the md5 sum of the ROM and request the backend data from the online register
• we need a new auto detection method.
• if the register is down or unavailable all PlusROMs won't work!

 

p.s.

I have set up an new shorter subdomain "h.firmaplus.de" which also points to the same path at the server. And a new script "a.php" which points to "api.php", so the URL definition for the high score backend can now be 10bytes shorter. Maybe i can also set up an .htaccess rule in that path, that connects a single file "a" with the php interpreter.

 

p.p.s

URL shortener like "bit.ly" will most likely not work because they use "https" and a redirect (301) to the target URL. This might work with Javatari, but not with the PlusCart implementation of the PlusROM functions.

[+Al_Nafuur]

13 minutes ago, Al_Nafuur said:

I have set up an new shorter subdomain "h.firmaplus.de" which also points to the same path at the server. And a new script "a.php" which points to "api.php", so the URL definition for the high score backend can now be 10bytes shorter. Maybe i can also set up an .htaccess rule in that path, that connects a single file "a" with the php interpreter.

i have set up a (internal) redirect "a" for the api.php path so the shortest backend definition we can get for the current high score API is:

    .byte "a", #0
    .byte "h.firmaplus.de", #0

17 bytes

 

[+Al_Nafuur]

the Domain "phc.de" (for pluscart-highscore-club) is currently available.

This would save 8 more bytes and reduce the definition to 9 bytes. But would cost 15,60 €/per year with my hoster

?

Edited March 20, 2020 by Al_Nafuur

[Thomas Jentzsch]

I think the interrupt vector and the 17 bytes short definition should do the job.

[Thomas Jentzsch]

21 hours ago, Al_Nafuur said:

I don't like these kind of hacks and solutions that only work with one use case.

Usually I would agree. But I am pretty sure this will become the most common use case. And maybe by far! The shortened URL helps, but especially for existing ROMs, finding the few necessary bytes in the 1st bank will not always be easy.

[Dionoid]

On 3/20/2020 at 11:12 AM, Al_Nafuur said:

I don't like these kind of hacks and solutions that only work with one use case. Opening this feature to all developer means we have to implement and maintain a "PlusROM backend database" in ever PlusROM enabled device and emulator. But this would need a new release for all, if a new backend is added.

I think that a set of standard "PlusROM API services" would be very helpful to most developers. Keeping the high scores for your game would be a commonly requested feature; Setting up (and maintaining) a backend database + API yourself is probably not trivial for most '2600 homebrew developers.

 

Also, a shared high score board will draw the attention of players and might increase the number of people buying/building PlusCarts. I'm not sure if you plan on selling PlusCarts in the future, but if so, centralized high score boards would help the sales.

 

Edited March 22, 2020 by Dionoid

[+Al_Nafuur]

14 hours ago, Dionoid said:

I think that a set of standard "PlusROM API services" would be very helpful to most developers.

 

On 3/20/2020 at 9:13 AM, Dionoid said:

Maybe, for existing games with only a small amount of free bytes, a predefined value in the interrupt vector (e.g. value $FFFF) could be interpreted by the PlusCart to use the hardcoded highscore API at highscore.firmaplus.de. That would save 31 bytes of ROM, which for existing games is a lot IMO.

I think the NMI vector and the shorter URL should be enough, maybe a shorter domain (eg. phc.de) if more developer are having trouble to find enough space in their existing games.

 

exceptions are always nasty. One problem is, the less bytes we try to use the higher is the risk of false positive detection. A valid internet hostname or a IP addresse, at the address the NMI points to, is part of the PlusROM detection. There are a lot of ROMs out there which might have $ffff (or any other value we choose) at the NMI vector. They would be interpreted by the PlusCart and emulators as PlusROM using one of the standard APIs. And they would send a request to the "detected" standard API each time the "WriteSendBuffer" hotspot is read in any bank.

 

16 hours ago, Dionoid said:

Keeping the high scores for your game would be a commonly requested feature; Setting up (and maintaining) a backend database + API yourself is probably not trivial for most '2600 homebrew developers.

Every developer is welcome to use the "PlusCart High Score Club" API for his game(s), but therefor he has to register the game somehow. Setting up your own back end gives you more freedom to implement your own features and design

 

16 hours ago, Dionoid said:

Also, a shared high score board will draw the attention of players and might increase the number of people buying/building PlusCarts. I'm not sure if you plan on selling PlusCarts in the future, but if so, centralized high score boards would help the sales.

I have set up the high score club just for a prof of concept. But apparently it draws the most attention.

And there are a lot of features missing in the actual high score club and his API (like screenshots, descriptions, sorting by game variant, names for the game variants, user avatars, API responding with the top 10)

I plan to build and sell at least a small batch of about 50 PlusCarts by myself, but i am also open for other solutions, if there are much more orders or someone wants to produce and sell PlusCarts in larger amounts.

[+Al_Nafuur]

To give developer and user the possibility to autostart a ROM at startup I've build in a autostart function for offline ROMs:

 

The PlusCart don't needs to be online, to start a ROM from the offline flash (Although an online autostart function would also be possible).

 

This function gives developers the opportunity to build and sell "branded" PlusCarts. The example in the video is @Andrew Davie 's Chess. He came up with the autostart idea, because he is looking for a way to release his chess program with the PlusCart and add more features or updates later.

 

The current autostart solution is: A User has to upload a ROM that starts with "Autostart." to his nextcloud "Offline" folder and then selects "Setup" -> "Download offline ROMs" at the PlusCart menu. Or a Developer does it via his account before he ships the branded PlusCart (of course disconnecting the cart from his account before shipping). The autostart file (as tar-archive) can also be flashed with the STM32CubeProgrammer, then connecting and disconnecting to an account is not necessary.

 

But there is currently no mechanism to get out of the started ROM into the PlusCart menu. To get rid of the autostart ROM, the flash area for the offline ROMs has to be erased with the STM32CubeProgrammer.

 

Exiting or restarting a ROM might be an interesting feature for the UnoCart (and all other Multicarts) aswell.

 

So we need to find a new "hotspot" for ROMs to signal to the PlusCart (or any other Multicart), that they want to exit the emulation and return to the Multicart menu or want a restart. This hotspot must/should be a "hotspot" that is not yet used in any bankswitching method.
 

I thought of using $0F7F (TIA mirror below $1000) as hotspot for exit emulation, restart requests or maybe other request to the multicart. I have mentioned these mirrors before in an post above about the PlusROM hotspots.

 

Maybe @Thomas Jentzsch, @DirtyHairy or @Dionoid have some proposals

 

 

 

Edited August 12, 2020 by Al_Nafuur

[+Andrew Davie]

1 hour ago, Al_Nafuur said:

 

I thought of using $0F7F (TIA mirror below $1000) as hotspot for exit emulation, restart requests or maybe other request to the multicart. I have mentioned these mirrors before in an post above about the PlusROM hotspots.

If you use BRK, then the reset vector could be used to indicate to the PlusCart exactly what you want to do.

PlusCart could distinguish from BRK used in legacy ROMS because of a signature/contents in the BRK reset vector.

In my use/case, I would switch in RAM to the reset vector area, and write $FFFE/$FFFF with the PlusCart signature+command and then BRK

Just throwing this out there to get people thinking.

 

 

 

[+Andrew Davie]

1 hour ago, Andrew Davie said:

If you use BRK, then the reset vector could be used to indicate to the PlusCart exactly what you want to do.

PlusCart could distinguish from BRK used in legacy ROMS because of a signature/contents in the BRK reset vector.

In my use/case, I would switch in RAM to the reset vector area, and write $FFFE/$FFFF with the PlusCart signature+command and then BRK

Just throwing this out there to get people thinking.

 

 

 

 

Expanding on this...

 

I'm just thinking out loud, and perhaps my understanding of how it all works is not correct. Something to discuss, anyway...

 

6502/7 BRK will set bit 4 (B-bit) of the saved status register that is pushed on the stack.

So, the PlusCart has a way of telling if it's a BRK instruction in action.

 

Assume I want to call a PlusCart function (say, "exit from game").

First I want to do a write to $FFFE/$FFFF to indicate that's what I want. So,

PLUSCART_SIGNATURE = %1010000000000000
MODE_EXIT = 1
PLUS_EXIT = PLUSCART_SIGNATURE + MODE_EXIT

    lda #<PLUS_EXIT
    sta $FFFE
    lda #>PLUS_EXIT
    sta $FFFF
      
    brk

 

PlusCart should special-case $FFFE/$FFFF access - when it sees those addresses it knows it's a write (if no BRK was in effect)

When the brk is executed, the following occurs...

 

store PC(hi)

store PC(lo)

store P

fetch PC(lo) from $FFFE

fetch PC(hi) from $FFFF

Now we can determine if $FFFE access here is read or write by the presence of the B-bit in the "store P" part
Am assuming the PlusCart can detect/handle this difference between a write to $FFFF/E and a read from $FFFF/E

Now at this point, the 6507 game having already stored "PLUS_EXIT" as the word at $FFFE/F - and this being a 'brk' being executed, the PlusCart knows that it needs to continue and do PlusCart stuff. But the 6502/7 is expecting PC (from $FFFE/F) to continue its stuff. So, PlusCart needs to feed it a pointer to a "PlusCart" routine in the game ROM itself so that the 6507 doesn't runaway into no-man's land.

 

This "PlusCart" routine needs to be some way of 'tricking' the 6507 into an idle state, where it does not actually receive any data on the buss. If we could get it to do a branch back to itself, this would do the trick. The opcode for "JMP" is $4C.  If somehow we could have the following...

 

    org $4C4C
endless    jmp endless

Then that code would assemble to $4C $4C $4C and in fact it would work even if the PlusCart wasn't feeding data to the 6507. That is, if the data bus held $4C then we wouldn't get a runaway program counter - the 6507 would be in an effective hold/idle loop. I think that might work?

 

So, once the PlusCart has done its stuff (let's say we were asking it to do a task for the program, such as retrieve a chess move from an external engine), now the PlusCart wants to return with status/data and have the 6507 continue from where it left off.  PlusCart is going to see an address request for $4C4C, 4D and 4E. At this point it knows the 6507 is in an idle loop and still in effect responding to the BRK from earlier on.  So rather than $4C4C (which is what the endless-loop has been "getting" from the bus), now the PlusCart has the opportunity to feed the 6507 a vector to a handler in the ROM for dealing with PlusCart returns.

In that case, that can be anything really, but that routine to which PlusCart returns (i.e., game continues from)...

 

* read $FFFE/$FFFF (again, read is detected by bit 4 set in status register)
* this gives some pointer to data, or action to take, or status, based on PlusCart results.

 

Well, I'm sure there's a gotcha in there somewhere. I'm a bit vague today. But in essence I'm proposing a two-way mechanism for games to communicate with PlusCart and offload processing to external code via BRK (and B-flag) and reads/writes to $FFFE/FF.  Along with, of course, the 4C4C4C "trick".

 

 

[+Al_Nafuur]

15 hours ago, Andrew Davie said:

If you use BRK, then the reset vector could be used to indicate to the PlusCart exactly what you want to do.

PlusCart could distinguish from BRK used in legacy ROMS because of a signature/contents in the BRK reset vector.

In my use/case, I would switch in RAM to the reset vector area, and write $FFFE/$FFFF with the PlusCart signature+command and then BRK

Just throwing this out there to get people thinking.

I like the idea of using BRK and reset vector to identify a exit request, but i am afraid this is not going to work with a multicart.

• The read/write line is not wired to the cartridge, so the cart can not determine if the CPU want's to read or write.
• The Multicart has (mostly) no idea what the 6507 is doing with the data it is requesting and what the data means. (e.g $00 could mean BRK, but could also be part of an address as in "LDA $1000", or could be data for the playfield, players, colors or what ever).

 

15 hours ago, Andrew Davie said:

6502/7 BRK will set bit 4 (B-bit) of the saved status register that is pushed on the stack.

So, the PlusCart has a way of telling if it's a BRK instruction in action.

Multicarts can not see the stack directly. They might monitor every read and write (which they can't distinguish) on the bus to the stack, but they hardly can tell where the stack ends and where RAM starts.

 

15 hours ago, Andrew Davie said:

Now at this point, the 6507 game having already stored "PLUS_EXIT" as the word at $FFFE/F - and this being a 'brk' being executed, the PlusCart knows that it needs to continue and do PlusCart stuff. But the 6502/7 is expecting PC (from $FFFE/F) to continue its stuff. So, PlusCart needs to feed it a pointer to a "PlusCart" routine in the game ROM itself so that the 6507 doesn't runaway into no-man's land.

 

This "PlusCart" routine needs to be some way of 'tricking' the 6507 into an idle state, where it does not actually receive any data on the buss. If we could get it to do a branch back to itself, this would do the trick. The opcode for "JMP" is $4C.  If somehow we could have the following...

 

    org $4C4C
endless    jmp endless

Then that code would assemble to $4C $4C $4C and in fact it would work even if the PlusCart wasn't feeding data to the 6507. That is, if the data bus held $4C then we wouldn't get a runaway program counter - the 6507 would be in an effective hold/idle loop. I think that might work?

Using $4C to let the 6502 "idle" sounds like a very good idea. DPC+ is setting the bus to $EA (NOP) but this increases the PC and the Harmony/Encore have to finish the ARM/Thumb code and return before the PC is in the (mirrored) TIA area and the 6502 is starting to ask the TIA what he should do next.

But there are two Problems with $C4.

• we must check that $4c4c is not a mirrored address of an other VCS chip (RIOT ?).
• the ARM can come back after every NOP and continue with something else. With the $4C solution this is not that easy, because it is every 3th $4C you can "jump" in (might be solvable by feeding 2x NOP before continuing).

16 hours ago, Andrew Davie said:

So, once the PlusCart has done its stuff (let's say we were asking it to do a task for the program, such as retrieve a chess move from an external engine), now the PlusCart wants to return with status/data and have the 6507 continue from where it left off.  PlusCart is going to see an address request for $4C4C, 4D and 4E. At this point it knows the 6507 is in an idle loop and still in effect responding to the BRK from earlier on.  So rather than $4C4C (which is what the endless-loop has been "getting" from the bus), now the PlusCart has the opportunity to feed the 6507 a vector to a handler in the ROM for dealing with PlusCart returns.

receiving data from an external server can be done by PlusROM functions (no idle loop necessary!)

 

[+Al_Nafuur]

Exit function works. In this video I start a modified version of River Raid. If the select switch is pressed the exit hotspot (currently $0f7f) is touched by the ROM to signal the multicart that it is now save to start the exit routine.

In the second part of the video I download the offline ROMs from my nextcloud account. The downloaded file is the modified River Raid just renamed to "Autostart.RiverRaid.bin". After restarting the PlusCart the file starts and by pushing the select switch the PlusCart exits and continues it's boot process to the main menu:

 

 

Edited August 11, 2020 by Al_Nafuur

[+Andrew Davie]

15 hours ago, Al_Nafuur said:

I like the idea of using BRK and reset vector to identify a exit request, but i am afraid this is not going to work with a multicart.

• The read/write line is not wired to the cartridge, so the cart can not determine if the CPU want's to read or write.

If you use the NMI vector (FFFA/FFFB) for read, and the BRK vector (FFFE/FFFF) for write, this seems to be a solution.

Write to BRK vector with command for PlusCart (+signature as described above).

Read from NMI vector to receive data from PlusCart. 16 bits possible.

 

Quote

• The Multicart has (mostly) no idea what the 6507 is doing with the data it is requesting and what the data means. (e.g $00 could mean BRK, but could also be part of an address as in "LDA $1000", or could be data for the playfield, players, colors or what ever).

Yes, I realise this.

But when 6507 hits a BRK instruction, it fairly rapidly accesses memory in a known and detectable order as described above.

In particular, values are written to the stack and more specifically the BRK vector (FFFE/FFFF) is accessed.

I'm suggesting this sequence of events could be detected.  Specifically when the B bit of the status register (which is one of those writes to the stack) is set, and followed a few accesses later by access to FFFE and FFFF in sequence. This would be a clear and detectable signature of a BRK, surely?

 

Quote

Multicarts can not see the stack directly. They might monitor every read and write (which they can't distinguish) on the bus to the stack, but they hardly can tell where the stack ends and where RAM starts.

I understand. But that doesn't matter. If you look for access to the BRK vector (FFFE immediately followed by FFFF - assuming that's the correct order) then you know you've hit a BRK instruction. You can also check if your preceeding data values (one byte earlier) which is the P value in the case of a BRK instruction has the B bit set. I think you could detect, in this situation, that there's actually a BRK without having to know anything about RAM or current stack top.

 

Quote

Using $4C to let the 6502 "idle" sounds like a very good idea. DPC+ is setting the bus to $EA (NOP) but this increases the PC and the Harmony/Encore have to finish the ARM/Thumb code and return before the PC is in the (mirrored) TIA area and the 6502 is starting to ask the TIA what he should do next.

But there are two Problems with $C4.

• we must check that $4c4c is not a mirrored address of an other VCS chip (RIOT ?).

OTOH, the chances of ANY prior ROM accessing this mirrored address is next to zero.

And in any case, a quick check suggests to me that $4C is neither in TIA nor RIOT memory spaces. I think $4C4C is "safe".

 

Edit: $4C appears to be a mirror address of REFP1.

 

Quote

• the ARM can come back after every NOP and continue with something else. With the $4C solution this is not that easy, because it is every 3th $4C you can "jump" in (might be solvable by feeding 2x NOP before continuing).

 

I don't think this is an issue.

Because we have a known location ($4C4C) for the opcode, the ARM can simply abort (leave the bus at $4C) until the address requested is $4C4D. In other words effectively ignore the 6502 data request (keep the 6507 'idle') until it actually requests a jump address operand. And that's via access to $4C4D, as noted. At that point we can feed it (say) $4C4F/$4C50 which is the byte after the 'endless loop' and where the programmer can continue the code with whatever they require. I'd put a jump vector table call in there, or something like that, which would be generic.
So, I think that might solve that issue.

 

Quote

receiving data from an external server can be done by PlusROM functions (no idle loop necessary!)

 

OK, but the ARM still needs to be handling data to the bus, right?

 

 

 

 

Edited August 12, 2020 by Andrew Davie

[+Al_Nafuur]

10 hours ago, Andrew Davie said:

If you use the NMI vector (FFFA/FFFB) for read, and the BRK vector (FFFE/FFFF) for write, this seems to be a solution.

Write to BRK vector with command for PlusCart (+signature as described above).

Read from NMI vector to receive data from PlusCart. 16 bits possible.

 

Yes, I realise this.

But when 6507 hits a BRK instruction, it fairly rapidly accesses memory in a known and detectable order as described above.

In particular, values are written to the stack and more specifically the BRK vector (FFFE/FFFF) is accessed.

I'm suggesting this sequence of events could be detected.  Specifically when the B bit of the status register (which is one of those writes to the stack) is set, and followed a few accesses later by access to FFFE and FFFF in sequence. This would be a clear and detectable signature of a BRK, surely?

 

I understand. But that doesn't matter. If you look for access to the BRK vector (FFFE immediately followed by FFFF - assuming that's the correct order) then you know you've hit a BRK instruction. You can also check if your preceeding data values (one byte earlier) which is the P value in the case of a BRK instruction has the B bit set. I think you could detect, in this situation, that there's actually a BRK without having to know anything about RAM or current stack top.

I am now a bit confused, what do we need all of this for again?

• For communication between the Multicart and the VCS ROMs?
  -> This could be done much easier with an "hotspot" that has not been used (in any bankswitching) before.
• For exit or restart requests from the ROM?
  -> This can also be done with "hotspot" communication. Also if you only think of it as a developer feature to restart/reload a changed ROM,
       it will also be of great use to the user to exit the ROM on a multicart.
       And with a write hotspot there can be communicated 256 different states (0 for exit, 1 for restart/reload and we still have 254 left).

 

BTW. the exit, restart/reload hotspot could also be used for online ROMs in the users/developers nextcloud folder or for the files on the SD card of the UnoCart (or Harmony/Encore if they want to add that feature for their Users)

 

10 hours ago, Andrew Davie said:

OTOH, the chances of ANY prior ROM accessing this mirrored address is next to zero.

And in any case, a quick check suggests to me that $4C is neither in TIA nor RIOT memory spaces. I think $4C4C is "safe".

 

Edit: $4C appears to be a mirror address of REFP1.

 

I don't think this is an issue.

Because we have a known location ($4C4C) for the opcode, the ARM can simply abort (leave the bus at $4C) until the address requested is $4C4D. In other words effectively ignore the 6502 data request (keep the 6507 'idle') until it actually requests a jump address operand. And that's via access to $4C4D, as noted. At that point we can feed it (say) $4C4F/$4C50 which is the byte after the 'endless loop' and where the programmer can continue the code with whatever they require. I'd put a jump vector table call in there, or something like that, which would be generic.
So, I think that might solve that issue.

 

If $4C4C is "safe" this procedure could be used for DPC+ or other ARM enhanced bankswitching types, and it would solve the running away PC problem. For the typical DPC+ games where the VCS has to draw a screen between VBLANK and Overscan this wouldn't be a big enhancement, but  if you want to move your chess engine to the ARM this would be a nice feature, because you wouldn't need to interrupt your ARM code to keep the VCS PC from getting lost.. 

 

 

10 hours ago, Andrew Davie said:

OK, but the ARM still needs to be handling data to the bus, right?

This is done by the 256 byte ring buffer at $1ff1 (ReceiveBuffer). See PlusROM specs: http://pluscart.firmaplus.de/pico/?PlusROM

BTW. you have already used this buffer last year for downloading the sokoboo levels from the online DB.

 

Edited August 12, 2020 by Al_Nafuur

[+Andrew Davie]

6 hours ago, Al_Nafuur said:

 

If $4C4C is "safe" this procedure could be used for DPC+ or other ARM enhanced bankswitching types, and it would solve the running away PC problem. For the typical DPC+ games where the VCS has to draw a screen between VBLANK and Overscan this wouldn't be a big enhancement, but  if you want to move your chess engine to the ARM this would be a nice feature, because you wouldn't need to interrupt your ARM code to keep the VCS PC from getting lost.. 

 

 

I don't know where 4C4C actually is as far as PC counter on 6507.

I'm looking into it. I'm not having any luck so far. It may not be possible.

[+Al_Nafuur]

17 hours ago, Andrew Davie said:

 

I don't know where 4C4C actually is as far as PC counter on 6507.

I'm looking into it. I'm not having any luck so far. It may not be possible.

0x4C4C -> 0b0100 1100 0100 1100

with only 13 address lines this equals to:

0b0000 1100 0100 1100 -> 0x0C4C

 

this should be a TIA mirror according to mem_map_1.txt from the mirrored memory thread (https://atariage.com/forums/topic/192418-mirrored-memory/?do=findComment&comment=2439795 :

 

$0C40-$0C7F = TIA Addresses $00-$3F   (mirror)

 

as you previously suggested  a mirror of $0C:
REFP1 ds 1 ; $0C 0000 x000 Reflection Player 1

 

is REFP1 a readable TIA address?

[+Andrew Davie]

8 hours ago, Al_Nafuur said:

 

as you previously suggested  a mirror of $0C:
REFP1 ds 1 ; $0C 0000 x000 Reflection Player 1

 

is REFP1 a readable TIA address?

 

$0C corresponds to read address INPT4