GroovyBee Posted August 6, 2016 Share Posted August 6, 2016 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.basFindECS.romFor 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. Quote Link to comment Share on other sites More sharing options...
freewheel Posted August 6, 2016 Share Posted August 6, 2016 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. 1 Quote Link to comment Share on other sites More sharing options...
intvnut Posted August 6, 2016 Share Posted August 6, 2016 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. Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted August 6, 2016 Author Share Posted August 6, 2016 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. Quote Link to comment Share on other sites More sharing options...
+Tarzilla Posted August 6, 2016 Share Posted August 6, 2016 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? Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted August 6, 2016 Author Share Posted August 6, 2016 JLP maps 16bit RAM to $8040 to $9EFF Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.