6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Fri Nov 22, 2024 11:12 pm

All times are UTC




Post new topic Reply to topic  [ 14 posts ] 
Author Message
PostPosted: Sun Nov 27, 2016 9:11 am 
Offline

Joined: Wed Jul 20, 2016 2:14 am
Posts: 78
Location: Irkutsk, Russia
Maybe, a trite subject-matter, but I keep worry about :( .
It seems, simplified address decoding allows attempts of several I/O devices to drive data bus simultaneously.
Somebody can tell me, I should make careful coding and use correct I/O addresses only. I agree.
Does this mean that designing machine language monitor I must disable an I/O memory browsing ? To display a memory range, the utility reads each and all location in a row, indiscriminately... Or BASIC cycle (for example):
For ... to ...
Print Peek
and so on...
Is it dangerous for soft- and hardware?

Vladimir


Top
 Profile  
Reply with quote  
PostPosted: Sun Nov 27, 2016 4:25 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8544
Location: Southern California
I've been using the simplified address decoding I show in the 6502 primer for 23 years and never had a problem. As far as just reading a range of addresses in the memory map assigned to memory, keep in mind that that's something you don't want to do anyway because merely reading changes status in some cases. You might dump bytes you needed in an input buffer, initiate extra reads before you're ready, erase an interrupt just as it's happening, reset bits that are there to tell you of an error condition, etc.. I'd say don't do it.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?


Top
 Profile  
Reply with quote  
PostPosted: Sun Nov 27, 2016 4:38 pm 
Offline
User avatar

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3367
Location: Ontario, Canada
[ LOL! I see Garth's a faster typist than I am. Also he touches on a point I overlooked -- namely, that merely reading can change status in some cases. The IFR of a 6522 is one example -- reading that register can change its contents. My comments are more general. Vladimir's post raises other questions worth examining.]

Most computers have address decode logic which, for any particular address, will activate only one memory / IO device -- or possibly none, but never more than one. OTOH other computers use decode logic which, for cost or space reasons, is simplified, and the "one device at a time" rule has exceptions. For example, supposing there are two IO devices, you might find there's...
  • a portion of the CPU address range in which neither IO device activates
  • a portion of the CPU address range in which device A activates
  • a portion of the CPU address range in which device B activates
  • a portion of the CPU address range in which device A and B both activate
Code that's written specifically for accessing these devices won't use the "neither" range or the "both" range. But other, more general code (like your examples) might.

A read or write access to the "A" or to the "B" range is what you'd call business as usual. The only caveat is the one Garth raised.

A write access to the "neither" range produces no effect, and is harmless. A read access is harmless for hardware, but the data returned is somewhat unpredictable. Presumably the software won't succeed or fail based on such an access, so there's no harm there, either.

A write access to the "both" range is "heard" by both devices, and that could even be useful! But a read access to the "both" range is the problem we need to discuss. When two devices are simultaneously commanded to drive the data bus, the result (ignoring the unlikely case where both devices happen to read identical data) is bus contention.

Vladimir wrote:
Is it dangerous for soft- and hardware?
The data returned is undefined, so the software mustn't succeed or fail based on such an access. But it's not worth worrying about, since in these circumstances it's impossible to define success! As for the hardware, nobody will recommend bus contention. It's guaranteed to result in an abnormally high current flow from the outputs of the two devices involved. Nevertheless, the probability of damage is small. If you don't notice the chips getting hot then you're probably OK. I realize that doesn't sound very scientific!

Remember the excess current flow occurs only during cycles for which the devices are accessed. Because those cycles are typically very much in the minority the heating effect will be small -- IOW the average dissipation is tolerable.

Two final notes. Modern, CMOS devices are capable of higher output current than older devices -- especially NMOS. So if you're using only NMOS I wouldn't worry at all about contention causing permanent hardware damage.

The other issue is VCC supply noise resulting from the excess current associated with contention -- especially in the absence of adequate decoupling capacitors. This won't cause any permanent damage, but it can be enough to upset the software.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html


Top
 Profile  
Reply with quote  
PostPosted: Sun Nov 27, 2016 7:50 pm 
Offline
User avatar

Joined: Sun Jun 30, 2013 10:26 pm
Posts: 1949
Location: Sacramento, CA, USA
I am reminded of my early days poking around in the Apple ][ monitor. Dumping or disassembling a range in the $C0xx area would trigger unpredictable side-effects from reading the soft-switches controlling the display mode. I learned to stay away from them, but I suppose that it wouldn't be too difficult to automatically exclude a range in your monitor routines, and replace the read values with "??" or whatever.

Mike B.


Top
 Profile  
Reply with quote  
PostPosted: Sun Nov 27, 2016 8:45 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8544
Location: Southern California
Dr Jefyll wrote:
A write access to the "both" range is "heard" by both devices, and that could even be useful!

I have never taken advantage of this, but it crosses my mind from time to time. A minor advantage would be for example to set up two UARTs the same. A greater advantage might be to trigger two events at the same time, with no delay between them, like starting timers.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?


Top
 Profile  
Reply with quote  
PostPosted: Mon Nov 28, 2016 3:20 am 
Offline

Joined: Wed Jul 20, 2016 2:14 am
Posts: 78
Location: Irkutsk, Russia
Thank you comrades, you have considerably corrected my world view.
Maybe, machine language monitor, which starts, should offer the user some kind of IQ test to figure out his mental abilities, before starting work...(I myself can not pass...). Or, when accessing dangerous memory locations, to issue a warning: "XXX area! Please confirm you are 18 or more years old!" :D
In short and no joke, the conflicts on the data bus are not the only problem. Display the whole range of IO is a senseless thing for many reasons. Therefore, from this point of view, simplified decoding has the right to life. I'll take your advice into consideration.

Vladimir


Top
 Profile  
Reply with quote  
PostPosted: Mon Nov 28, 2016 10:18 am 
Offline

Joined: Wed Jul 20, 2016 2:14 am
Posts: 78
Location: Irkutsk, Russia
An idea arose. Maybe, memory protection helps?
IO access permission for OS_ROM only! The hardware seems to be simple. It's necessary to have a register, that constantly contains the address of last fetched opcode for the moment ( not entire address, several high order bits only) and, accessing IO, we will check that opcode belongs to the OS_ROM... Is it possible?


Top
 Profile  
Reply with quote  
PostPosted: Mon Nov 28, 2016 6:32 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8544
Location: Southern California
If it's used as a controller in a realtime system of any kind, you cannot limit I/O to OS calls. It is much, much too slow.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?


Top
 Profile  
Reply with quote  
PostPosted: Mon Nov 28, 2016 6:39 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10986
Location: England
(Just as a point of reference, Acorn's Master line of computers does use the address of an instruction fetch to influence the memory map: the screen memory is, in some modes, only visible to instructions which run from the addresses which correspond to the OS VDU drivers. So, monitoring Sync like this is an idea with a pedigree!)


Top
 Profile  
Reply with quote  
PostPosted: Tue Nov 29, 2016 2:04 am 
Offline
User avatar

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3367
Location: Ontario, Canada
As a further point of reference, the KIM-1 microcomputer has a single-instruction stepping scheme that takes action based on where instructions are fetched from. Instructions fetched from the ROM (where the monitor program is stored) get no special treatment -- they proceed at full speed. But if ever SYNC is true and the ROM Chip-Select is not (ie, an opcode is being fetched, but not from ROM) then NMI\ gets pulled low. That one instruction fetched from outside ROM *will* execute before the interrupt commences, and that's the basis of the single-stepping scheme.

The NMI passes control back to ROM code, and that's what keeps the 7-seg LED display illuminated and lets you examine memory and registers to see the result of each single step.

I wonder if the 6502 designers provided the SYNC pin specifically to support this simple but valuable technique!

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html


Top
 Profile  
Reply with quote  
PostPosted: Tue Nov 29, 2016 3:39 am 
Offline

Joined: Wed Jul 20, 2016 2:14 am
Posts: 78
Location: Irkutsk, Russia
It seems that all good things have already been invented before us. :(
We can only enjoy all this and eating popcorn.


Top
 Profile  
Reply with quote  
PostPosted: Tue Nov 29, 2016 8:58 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10986
Location: England
Vladimir wrote:
It seems that all good things have already been invented before us. :(
We can only enjoy all this and eating popcorn.

I'd say instead that all good things have already been invented before us :D 8) :shock: !

Bret Victor did a retrotastic talk about the future history of computer science - recommended viewing!
The Future of Programming
Image


Top
 Profile  
Reply with quote  
PostPosted: Tue Nov 29, 2016 8:25 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8544
Location: Southern California
Rather O.T., but thankyou Ed for the good laugh. How did he get through that with a straight face?! There was even the pocket protector, and the overhead projector (although it was made to shine over to the side). He just needed a corded lavalier mic (the kind with a neck strap), and get rid of the modern water bottle! :lol:

We're still using text files though. Structured programming has gotten rid of the need for graphic-oriented flowcharting.

He says they've realized the importance in not having delays in the UI or OS, so there won't be any by 2013. Yeah, right! :lol:

I will reiterate however that the home computers of decades ago could have been more capable, even with the same hardware, if software ideas had been better developed at the time. Things were all new and wonderful, yet there was mystery and insecurity about where it would all go, which companies and systems would survive the coming shakedowns, etc..

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?


Top
 Profile  
Reply with quote  
PostPosted: Tue Nov 29, 2016 10:50 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8507
Location: Midwestern USA
GARTHWILSON wrote:
He says they've realized the importance in not having delays in the UI or OS, so there won't be any by 2013. Yeah, right! :lol:

Microsoft Windows is one big delay after another. :evil:

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 14 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: