Jump to content
IGNORED

[IntyBASIC] Detecting the ECS


Recommended Posts

I've seen a couple of requests for detecting the ECS in IntyBASIC. A simple way to detect the ECS is to write an 8 bit value to its RAM (somewhere between $4000 and $47FF) and then read it back. If the value you read back matches the value just written, then do the same write/read/check operation again to make sure the first one wasn't a fluke. If the 2nd write/read/check works as expected then the ECS is connected. ECS RAM addresses between $4000 and $403F are best avoided due to STIC aliasing.

 

Source code and ROM:
FindECS.bas
FindECS.rom

For testing the ROM in the jzintv emulator you'll need to add the "--ecs=1" flag to its command line (without the quotes).

 

@nanochess: Feel free to include this in the next IntyBASIC release.

Link to comment
Share on other sites

Very cool, thanks for the help guys. I was originally trying to turn what DZ is doing into IntyBASIC statements. Just couldn't quite get it working for some reason.

 

Joe's 'try the PSG directly' worked well for me, and is "less code". Not that it really matters as this is always going to be something you just do at boot. I don't know if there are any differences between the methods, but before including in a general-purpose language I hope you guys hash out any edge cases to make sure we nail it on the first try :)

 

Ideally this should be in IntyBASIC as a very simple CONST/variable for a programmer. IF (ECS) THEN... exactly how NTSC works. I hope it can be incorporated that way, instead of an add-on #include type situation.

  • Like 1
Link to comment
Share on other sites

It should be safe to probe locations in the range $4000 - $403F that don't map to valid STIC registers. For example, $4022 - $4027, $402D - $402F, and $4033 - $403F. If those won't otherwise be used for data, then you don't need to worry about the probe corrupting any data.

 

It seems a shame to waste a full 8-bit variable to store ECS present/absent in addition to the 8-bit location that records NTSC/PAL. But, IntyBASIC could instead pack these as bits in a single byte. References to NTSC could pull out one bit, while references to ECS could pull a different bit. This could be extended to Intellivoice or any other presence detect.

 

That is, if someone said "IF ECS..." / "IF NTSC" / "IF VOICE" / etc. IntyBASIC could internally convert that to reading the byte and masking the interesting bit.

Link to comment
Share on other sites

It should be safe to probe locations in the range $4000 - $403F that don't map to valid STIC registers. For example, $4022 - $4027, $402D - $402F, and $4033 - $403F. If those won't otherwise be used for data, then you don't need to worry about the probe corrupting any data.

Its not really an issue poking into ECS RAM because IntyBASIC doesn't place any variables into it.

Link to comment
Share on other sites

I'm stuck with really crappy internet at the moment or I would look it up myself, but do the current boards with ram, as well as the CC3, map ram to the same range as the ECS?

More specifically, if we include the --jlp flag, would the ram poke/peek test pass as if it's an ECS?

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...
 Share

  • Recently Browsing   0 members

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