Difference between revisions of "Talk:83Plus:Ports:05"

Revision as of 16:09, 21 July 2005

I'm not sure how I feel about calling this "RAM Paging port", because all of 05,06, and 07 can be used to page in RAM. Personally I think that if we designate 0000-3FFF as bank0, 4000-7FFF as bank1, 8000-BFFF as bank2, and C000-FFFF as bank3 it will be the clearest. Then we can say port 5 controls bank3, port 6 controls bank1, and port 7 controls bank2. --Dan Englender 09:46, 28 Mar 2005 (PST)

Well, does it even make sense to assign a bank number to 0000h~3FFFh, since that's permanently set as ROM Page 0? Also another option would be to just call them by the address block they effect (or at least the first address)? Eg, bankC000, bank4000, bank8000? --Aquanight 15:47, 30 Mar 2005 (PST)

I've heard them be called the 0000, 4000, 8000, and C000 banks before, so that would seem to be a good choice. I would go with this one...and at least these names can't result in any possible confusion at all. Simple and elegant. --JasonM right now

I don't see why not to assign a bacnk number to 0000-3FFF. Just because the data in there isn't changing doesn't mean it's not useful to talk about it. Memory is logically split into these four different segments, so it's useful to have names for all of them. --Dan Englender 08:32, 31 Mar 2005 (PST)

Should it be pointed out somewhere that only when the port is 0 (RAM page 0 selected) that execution is forbidden above address C000h? --Aquanight 15:10, 2 May 2005 (PDT)

Isn't all execution prevented on ram page 0 regardless of where it is? --AndyJ 15:13, 2 May 2005 (PDT)

Yes, but for people that might be semi-new to assembly it might be a good idea to point out *somewhere* that the execution limit is tied to the RAM page, and not the logical memory. Putting it here would seem to make the most sense :) . That or maybe somewhere in 83Plus:OS or something? --Aquanight 23:08, 3 May 2005 (PDT)

Well, it's a hardware thing, not an OS thing, so no it doesn't go there. It would go here. :) Someone fix that sometime, it's way too late for me to. :P --AndyJ 23:09, 3 May 2005 (PDT)

Added info about TI-83 Plus. Didn't know exactly how to separate BE with higher models given how radically different the behaviour of the port is, so I did what seemed logical and marked the page as non-standard. Also, the table could be better. Sigma 16:25, 18 Jul 2005 (PDT)

I'll fix the table later, once I've brushed up on wikitables. Also, I agree with how you split it. --Andy Janata 16:35, 18 Jul 2005 (PDT)

table == wikied. --Aquanight 16:59, 18 Jul 2005 (PDT)

83+ Link assist

As I didn't see this information in his text file, I'll post the log of #WikiTI here:

[13:17:41] <+Kalimero_> ooooh, I just found a link assist on the 83+
[13:17:49] <+Kalimero_> well, at least for receiving
[13:18:25] <+Gambit_> ..
[13:18:27] <+Gambit_> O_O
[13:18:37] <@Andy_J> really
[13:19:19] <+Kalimero_> yes, set bit 2 of port 0, wait for bit 3 to set and read port 5 to get the byte just received
[13:19:30] <@Andy_J> wow
[13:19:35] <+Gambit_> :O
[13:20:06] <+Kalimero_> so bit 2 of port 0 seems to enable the assist
[13:20:16] <@Andy_J> wiki update time!
[13:20:25] <+Gambit_> yay! :D
[13:20:32] <+Kalimero_> and bit 3 is set when there's a byte waiting
[13:20:44] <+Kalimero_> when you read port 5 bit 3 of port 0resets
[13:22:22] <+Kalimero_> well, I still have to figure out the details
[13:22:43] <+Kalimero_> bit 6 of port 0 means something too
[13:23:35] <+Kalimero_> might be a "busy receiving" flag
[13:24:01] <+Kalimero_> anyway, I wonder why ti built that in didn't use it
[13:24:32] <+Kalimero_> *and
[13:24:32] <+Peter_W> Maybe it's not something that has always been there?
[13:25:22] <+Kalimero_> could be, though you'd think hw features are tight to the boot code version
[13:25:29] <+Kalimero_> and only version 1.00 exists
[13:25:39] <+Gambit_> I'd say that too.
[13:25:40] <+Peter_W> true 

--Andy Janata 12:39, 21 Jul 2005 (PDT)