Talk:Motorola 6809
This is the talk page for discussing improvements to the Motorola 6809 article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find video game sources: "Motorola 6809" – news · newspapers · books · scholar · JSTOR · free images · free news sources · TWL · NYT · WP reference · VG/RS · VG/RL · WPVG/Talk |
This article is rated B-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||
|
This article is based on material taken from the Free On-line Dictionary of Computing prior to 1 November 2008 and incorporated under the "relicensing" terms of the GFDL, version 1.3 or later. |
SIMM, DIMM?
[edit]what do simm dimm stand for. — Preceding unsigned comment added by 196.4.80.2 (talk) 08:31, 10 October 2002 (UTC)
- Single inline memory module, and dual inline memory odule respectively. Why the question here, rather than the reference desk? ww 04:09, 13 May 2006 (UTC)
650x comparisons
[edit]Sure, the processors came out in roughly the same time period, had several designers in common, and similar design criteria - but the 650x is hardly a clone of the 6809. They're useful to compare and contrast, but they're hardly identical. What's the fascination with clamining one's a clone of the other? --moof 04:58, 16 November 2005 (UTC)
- The 6502 was an outgrowth of the earlier 6800. Chuck Peddle and people eventually ended up at MOS Technology, and their first effort the 6500 was deemed too close to the 6800 and an infringement on Motorola's design. It actually had little to do with the 6809, whose design was influenced by an analysis of large amounts of 6800 assembly code. The 6502 was used in many of the early machines (the KIM-1 (and other trainers), various Commodores, the Ataris, Apple I and II, ...) not for its great virtues as an architecture (quite limited, really), but because it was priced much lower than the somewhat comparable competition. As near as I could tell at the time, no such fascination was justified. ww 04:07, 13 May 2006 (UTC)
8MHz 68B09??
[edit]I´ve found a MC68B09P connected to a 7.3728 chrystal on an old circuitboard! —Preceding unsigned comment added by 81.228.208.41 (talk) 09:02, 23 October 2007 (UTC)
The internal clock is the crystal frequency divided by 4, so that 68B09P is running at 1.8432MHz.
--Lamune (talk) 06:50, 3 January 2008 (UTC)
- Check the data sheets. Motorola uses a divide-by-four circuit when connecting a crystal directly to a CPU that can generate it's own clock. Even the external clock generators tend to divide down from a clock 4 times as fast as the clocks fed to the CPU. It makes getting a clean clock easier, and, in the case of the 6809, it makes it fairly simple to derive the quadrature clock.
- Looking at this in the converse, the CPU clock is usually the same as the memory system clock and the clock provided to the peripheral parts, so a 2 MHz 6809 usually runs 2 MHz memory clock, which means comparing the clock speed to other CPUs requires knowing a little about how the memory for the other CPU derives its clock. Often, a 2 MHz 6809 is processing instructions faster than a 6 MHz Z80. 60.130.192.5 (talk) 09:18, 26 November 2022 (UTC)
Performance?
[edit]How does the 6809 compare to other CPUs of the time in terms of real-world performance per MHz? Please add this info if you have it. -- 92.229.88.194 (talk) 14:30, 25 March 2010 (UTC)
- Because of Motorola's choices on the relation between memory cycles and the CPU clock, other CPUs of the time had higher clocks (Z80 got up to 6MHz, IIRC) which made the 6800 and 6809 CPUs seem slow. However, each memory cycle in the Intel style processors (8080, 8085, z-80 etc) took many clock cycles. depending on the instruction. In addition, 6809 instructions were relatively more useful on a stand alone basis; the equivalent in other CPUs was often needing two or three instructions.
- So the answer to your question is not easy to discern. the 68xx 8-bit ships were much faster than people expected from clock speeds alone, but also gained relative speed for more obscure reasons. The answer is fast, faster than many competitors, even at the lower clock rate.
- Byte did an article which attempted to address this by creating a VAX-11 equivalent rating. They attempted ot normalize various differences, in a fuzzy atricle -- common in most of these benchmarking disputes. IIRC, the 6809 placed high, but not at the very top of the pile.
- The 40MHz 6809 emulator running on x86 is likely faster than anything of the period, by an order of magnitude or two. ww (talk) 06:05, 26 March 2010 (UTC)
- What was the title and author of that Byte article?
- Are you perhaps alluding to the VAX unit of performance (VUP)? --DavidCary (talk) 17:13, 26 December 2014 (UTC)
Heavy stress on position independant code
[edit]I can't see where the heavy stress on position independant code comes from. The 6809 and the 8086 both have relative branches and relative 16 bit calls. In fact with the use of segment registers reposition code is easier on the 8086 or even unnecessary. These were at the time competitors as were os9 and MS-DOS. I feel uncomfortable rephrasing this, but it doesn't feel right. (Of course OS9 did accommodate p.i.c.) 80.100.243.19 (talk) 21:42, 17 January 2015 (UTC)
- True PIC is more than just relative branches. It means the OS loader doesn't have to do fix-up, period. Code modules written appropriately can be delivered as ROMs and plugged in anywhere in the memory map where they don't conflict with I/O devices or interrupt vectors. Or, if you have virtual memory, you can have library functions loaded once in memory, and various processes can map that one instance to the addresses that fit with whatever else the process is using.
- Code for the 68000 and 6809 can be written that way.
- Code for the 8086, not really, especially if you are trying to use long pointers. MS-DOS required a relocating loader.
- Truth told, OS-9 sometimes required relocation tables for data because their entry-level tools did not handle self-referential data well, but that was a tools problem, not a CPU architecture problem.
- And you could, of course, write non-relocatable code for both the 68000 and the 6809. 60.130.192.5 (talk) 10:16, 26 November 2022 (UTC)
Please fix reference
[edit]I have added the official Motorola programming manual as reference. This should be moved from Further reading to (preferably the first) reference, because it is *the* primordial source on the 6809 instruction set. It is also referenced where I mention the assis09. Please help, because I don't know how to do that. — Preceding unsigned comment added by 80.100.243.19 (talk) 22:18, 17 January 2015 (UTC)
version numbers of processors conflict with what they can do more or less
[edit]if you have a 6809 E processor you have a processor brand say 6809 and the E stands for External Clock.
if you have a 6203 processor it is supposed to be an earlier processor. So it's instruction set could be less complicated.
It's a FACT processors which have a higher number are supposed to be more intelligent. Because why should you add the higher number without upgrades to the processor possibilities. The article is riddled with wrong processor numbers who would be perform less than the higher version ones. It would be good this should be repaired in this article. — Preceding unsigned comment added by 85.145.0.77 (talk) 19:00, 8 March 2017 (UTC)
External links modified (February 2018)
[edit]Hello fellow Wikipedians,
I have just modified 2 external links on Motorola 6809. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
- Added archive https://archive.is/20130701061311/https://student.brighton.ac.uk/burks/pcinfo/hardware/cpu.htm to https://student.brighton.ac.uk/burks/pcinfo/hardware/cpu.htm
- Added archive https://web.archive.org/web/20121004145431/http://mamedev.org/source/src/emu/cpu/konami/konami.c.html to http://mamedev.org/source/src/emu/cpu/konami/konami.c.html
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}}
(last update: 5 June 2024).
- If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
- If you found an error with any archives or the URLs themselves, you can fix them with this tool.
Cheers.—InternetArchiveBot (Report bug) 13:28, 6 February 2018 (UTC)
Example code
[edit]It would be nice to add an example subroutine, such as the strtolower()
example used for some of the other microprocessors (e.g., 6502, 80386, 68000, etc.). — Loadmaster (talk) 17:39, 22 May 2018 (UTC)
One of the first with a multiply instruction?
[edit]The TMS9900 (1975) and 8086 (1976) both had multiply instructions before the 6809. Heck, those two processors also had divide instructions as well. I believe even the 68000 came out before the 6809. Now, if you say "first 8 bit processor with a multiply instruction," sure. All the others I just mentioned were 16 bit CPUs. Being 4th, when the others beat you by years, stretches the title "one of the first." — Preceding unsigned comment added by 2620:15C:2C0:4:41E6:D39C:32A0:34EC (talk) 21:53, 24 May 2018 (UTC)
- FWIW, the article is misleading about the debut of the 6809. It debuted in 1978. The 68000 was developed concurrently with the 6809, but debuted a bit later.
- The 8086 started development in 1976, also debuting in 1978. 60.130.192.5 (talk) 09:39, 26 November 2022 (UTC)
Use in Data General peripherals
[edit]I worked at DG in 1987 to 1991 in the terminals group (Durham NH and then Westborough MA - “Webo”).
The Dasher series of character cell terminals were built around the 6809, including the D210-D213, D217, D410-D413, D460-D463, and D578E “security terminal.” Also the Panther series of dot matrix printers were built on the 6809.
In the terminals, the 68B09E was connected to a standard cell custom graphics chip called “HILT” (high integration level terminal), 8KB OTP PROM, 16KB SRAM, and 256KB DRAM that was used for video generation. The HILT did cycle-stealing to fetch the characters and attributes from SRAM, and did a look-up in DRAM to generate video. DRAM with the character bit patterns (or graphics) were loaded using a window mapped by HILT registers.
(Numbers above varied by model and are to the best of my recollection 30+ years later. :->) James.d.carlson (talk) 11:45, 9 September 2022 (UTC)
68C11 is not a variation of the 6809
[edit]Motorola did an analysis of code written for the 6800 and other 8-bit microprocessors, looking for bottlenecks and other places they could improve things, and the 68000 and 6809 projects were started on two independent concurrent tracks using what they learned from that analysis.
Motorola wanted a CPU to use as a core in SOCs, and the 6809 would have too many transistors for SOCs of the time frame, so they made some smaller improvements in the 6800 to make the 6801. (Fixed compare X, added 16-bit add, subtract, and shift, also added push and pop X -- small but really significant improvements.) The 6801 actually came out after the 6809, by a few months.
Even though the 6801 core did not use that many more transistors than the 6800, the customer wanted even less, so they could have more built-in peripherals -- advanced timers and such, so Motorola really pared things down and gave them the 6805, which started a really successful line in SOC/embedded. The 6805 removed the B accumulator and cut the index register in half, making it less of a pointer and more of an index register.
The 68HC11 simply extended the 6801 by adding a Y index register. Since it has none of the advanced addressing modes of the 6809, it really should not be presented as a variation of the 6809, or even a stripped-down 6809. It's a simple extension of the 6801, designed to keep the transistor count down to leave transistors available for built-in peripherals like those in the 6805.
These facts can be confirmed quickly be reference to the data sheets. 60.130.192.5 (talk) 10:04, 26 November 2022 (UTC)
- B-Class Computing articles
- High-importance Computing articles
- B-Class Computer hardware articles
- Unknown-importance Computer hardware articles
- B-Class Computer hardware articles of Unknown-importance
- All Computing articles
- B-Class video game articles
- Low-importance video game articles
- WikiProject Video games articles