Skip to main content
typos
Source Link
Raffzahn
  • 249.4k
  • 23
  • 722
  • 1k

It shows as well were the temporary byte location comes from. After all, stackStack relative addressing, as well as indexing was one of the main features of the 6809. In fact, looking at his changes it got much in common with the 8086 as beeingbeing developed with HLL constructs in mind (*1).

  • Stack order for Interrupt/SWI differ (IIRC A and B is swapped)

  • 6809 SP point to the last entry, while 6800 points to the next

  • 6809 addesadds E/F flag to the lagflag register where 6800 has fixed values of 11

  • TST does not affect C

  • Shifts do not affect V

It shows as well were the temporary byte location comes from. After all, stack relative addressing, as well as indexing was one of the main features of the 6809. In fact, looking at his changes it got much in common with the 8086 as beeing developed with HLL constructs in mind (*1).

  • Stack order for Interrupt/SWI differ (IIRC A and B is swapped)

  • 6809 SP point to the last entry, while 6800 points to the next

  • 6809 addes E/F flag to the lag register where 6800 has fixed values of 11

  • TST does not affect C

  • Shifts do not affect V

It shows as well were the temporary byte location comes from. Stack relative addressing, as well as indexing was one of the main features of the 6809. In fact, looking at his changes it got much in common with the 8086 as being developed with HLL constructs in mind (*1).

  • Stack order for Interrupt/SWI differ (IIRC A and B is swapped)

  • 6809 SP point to the last entry, while 6800 points to the next

  • 6809 adds E/F flag to the flag register where 6800 has fixed values of 11

  • TST does not affect C

  • Shifts do not affect V

added 1759 characters in body
Source Link
Raffzahn
  • 249.4k
  • 23
  • 722
  • 1k

For example, how compatible was it really?

But evenEven with this source code replacements, some incompatibilities exist:

Were any software titles known to have been built for both processors?

Like with many questions, it is important that the view of some users/gamers/hackers greatly differ from what chip makers have in mind when doing them. (Home-) Computers are just a tiny little fraction of their market. Not really important to design CPUs for it. Embedded has always been king and might hold this at least for all foreseeable future.

Take for example the beloved 6502. The number of desktop machines is puny compared to embedded application. There may have been some 30-40 million units used in computers (*2) but they represent less than a percent of the 5-10 billion units claimed on the WDC website. The situation can be considered the same for basically all other microprocessors as well.

Chip manufacturers care for their important market, and "software titles" are not what embedded systems run. Here also CPU generations don't get swapped by chance and at random points, but only when a new or updated device is made. This almost always include a redesign of the software, as it's about new features. Usually such a redesign needs a more powerful CPU or other new feature and engineers will go shopping for the best chip to perform, only held back by their penny counting department. And that's where (semi) automatic source conversion comes into play - they are sales tools to convince buyers that they get the power of a new chip but may save great on software development as much of the old program can be reused. A wet dream for management always wanting to get a grip on those strange guys in engineering and development :))

*1 - If they only had added a way to address more memory - like due segmentation - today's PCs might be 6809 based ... well, somewhere way deep down beneath many layers of later extensions :))

*2 - ca. 12.5 M C64, 6.5 M Apple II and let all other come double this

But even with this source code replacements, some incompatibilities exist:

*1 - If they only had added a way to address more memory - like due segmentation - today's PCs might be 6809 based ... well, somewhere way deep down beneath many layers of later extensions :))

For example, how compatible was it really?

Even with this source code replacements, some incompatibilities exist:

Were any software titles known to have been built for both processors?

Like with many questions, it is important that the view of some users/gamers/hackers greatly differ from what chip makers have in mind when doing them. (Home-) Computers are just a tiny little fraction of their market. Not really important to design CPUs for it. Embedded has always been king and might hold this at least for all foreseeable future.

Take for example the beloved 6502. The number of desktop machines is puny compared to embedded application. There may have been some 30-40 million units used in computers (*2) but they represent less than a percent of the 5-10 billion units claimed on the WDC website. The situation can be considered the same for basically all other microprocessors as well.

Chip manufacturers care for their important market, and "software titles" are not what embedded systems run. Here also CPU generations don't get swapped by chance and at random points, but only when a new or updated device is made. This almost always include a redesign of the software, as it's about new features. Usually such a redesign needs a more powerful CPU or other new feature and engineers will go shopping for the best chip to perform, only held back by their penny counting department. And that's where (semi) automatic source conversion comes into play - they are sales tools to convince buyers that they get the power of a new chip but may save great on software development as much of the old program can be reused. A wet dream for management always wanting to get a grip on those strange guys in engineering and development :))

*1 - If they only had added a way to address more memory - like due segmentation - today's PCs might be 6809 based ... well, somewhere way deep down beneath many layers of later extensions :))

*2 - ca. 12.5 M C64, 6.5 M Apple II and let all other come double this

added 617 characters in body
Source Link
Raffzahn
  • 249.4k
  • 23
  • 722
  • 1k

Just from memory the cases mentioned:

(hope I didn't add any typo or screw replacements)

But even with this source code replacements, some incompatibilities exist:

The 6809 as designed is reasonably compatible with the 6800, but with the added features some inconsistencies must exist. Mostly around stack and flags:

  • Stack order for Interrupt/SWI differ (IIRC A and B is swapped)

  • 6809 SP point to the last entry, while 6800 points to the next

  • 6809 addes E/F flag to the lag register where 6800 has fixed values of 11

  • TST does not affect C

  • Shifts do not affect V

Like with any automatic translation, the result should be put thru the same test bed as the original was.

Just from memory the cases mentioned:

(hope I didn't add any typo or screw replacements)

(hope I didn't add any typo or screw replacements)

But even with this source code replacements, some incompatibilities exist:

The 6809 as designed is reasonably compatible with the 6800, but with the added features some inconsistencies must exist. Mostly around stack and flags:

  • Stack order for Interrupt/SWI differ (IIRC A and B is swapped)

  • 6809 SP point to the last entry, while 6800 points to the next

  • 6809 addes E/F flag to the lag register where 6800 has fixed values of 11

  • TST does not affect C

  • Shifts do not affect V

Like with any automatic translation, the result should be put thru the same test bed as the original was.

added 866 characters in body
Source Link
Raffzahn
  • 249.4k
  • 23
  • 722
  • 1k
Loading
added 866 characters in body
Source Link
Raffzahn
  • 249.4k
  • 23
  • 722
  • 1k
Loading
Source Link
Raffzahn
  • 249.4k
  • 23
  • 722
  • 1k
Loading