3 ms·

That’s cool - the 6800 is getting its equivalent of the 65816

cmrdporcupine 2y ago
skimming, it looks limited to 16-bit memory addressing, so not really equiv unfortunately. '816 was a gross hack, but it at least let you get more memory on there without resorting to bankswitching
- PaulHoule 2y ago
  Kinda awful because it doesn’t have 24 bit index registers so writing programs that use the whole memory is a hassle. I remember people complaining a lot about messing with the segment registers in the 8086|8088 which was worse than having a flat memory space but really wasn’t that bad, you could always find a memory model that worked for your application and I really enjoyed writing 80286 assembly.
  - cmrdporcupine 2y ago
    yeah this is always my bitch with the 816. there's no way to have a "pointer" in a register as a single value. that and the stupid mode switching oh, and stack and zero page not being able move out of first bank not a compelling chip.
    - whartung 2y ago
      8086 doesn't support longer pointers either. You always had to load a segment and then an offset as two operations, no different from loading the DB (data bank register) in the '816. The DB was not as flexible as segment registers, and there was only one of them, but you could easily load them both and then get a 16 bit value into the accumulator. Index registers also crossed bank boundaries. In contrast to the 8086, where the segments were a bit of a jail. Mind, that's a feature in that you could write a multiprocessing system without memory protection, and have code reasonably safe from accidentally stomping on other areas (for example, if your C compiler compiled to the Tiny model, a rogue C ptr shouldn't be able to break out, obviously assembly could do anything). Regarding the 68K and larger address space, on the original Macintosh, you were unable to request a single block of memory larger than 32K. So, like the Genie, unlimited power -- itty bitty living space. Sure, pointers could access anything, but at a system level, you weren't going to get a large enough chunk of memory, all at once, to warrant a larger pointer, so you were working with almost "virtually" segmented memory anyway. On the IIGS, based on the 816, they used a similar memory manager. The segment manager on IIGS is really pretty cool. It's 2.0 of what the Macintosh had.
PixyMisa 2y ago
It sounds like it has similar (maybe the same) extensions as the Hitachi 6309 https://en.wikipedia.org/wiki/Hitachi_6309 https://en.wikipedia.org/wiki/Hitachi_6309 That is, it has a 32-bit accumulator (made up of four 8-bit accumulators) but apparently no address extensions.
- bjconlan 2y ago
  Wow I didn't know Hitachi made anything outside of their superh/sh CPUs (which also do a mixed encoding scheme) I'm guessing they derived it from these guys and appeased the risc crowds. Off topic but I wonder what ever happened to that j-core project. I have a feeling understanding/learning both the turbo9/6809 along with the j2/sh2 would make for a great comparison.

skimming, it looks limited to 16-bit memory addressing, so not really equiv unfortunately. '816 was a gross hack, but it at least let you get more memory on there without resorting to bankswitching

PaulHoule 2y ago
Kinda awful because it doesn’t have 24 bit index registers so writing programs that use the whole memory is a hassle. I remember people complaining a lot about messing with the segment registers in the 8086|8088 which was worse than having a flat memory space but really wasn’t that bad, you could always find a memory model that worked for your application and I really enjoyed writing 80286 assembly.
- cmrdporcupine 2y ago
  yeah this is always my bitch with the 816. there's no way to have a "pointer" in a register as a single value. that and the stupid mode switching oh, and stack and zero page not being able move out of first bank not a compelling chip.
  - whartung 2y ago
    8086 doesn't support longer pointers either. You always had to load a segment and then an offset as two operations, no different from loading the DB (data bank register) in the '816. The DB was not as flexible as segment registers, and there was only one of them, but you could easily load them both and then get a 16 bit value into the accumulator. Index registers also crossed bank boundaries. In contrast to the 8086, where the segments were a bit of a jail. Mind, that's a feature in that you could write a multiprocessing system without memory protection, and have code reasonably safe from accidentally stomping on other areas (for example, if your C compiler compiled to the Tiny model, a rogue C ptr shouldn't be able to break out, obviously assembly could do anything). Regarding the 68K and larger address space, on the original Macintosh, you were unable to request a single block of memory larger than 32K. So, like the Genie, unlimited power -- itty bitty living space. Sure, pointers could access anything, but at a system level, you weren't going to get a large enough chunk of memory, all at once, to warrant a larger pointer, so you were working with almost "virtually" segmented memory anyway. On the IIGS, based on the 816, they used a similar memory manager. The segment manager on IIGS is really pretty cool. It's 2.0 of what the Macintosh had.

PixyMisa 2y ago

It sounds like it has similar (maybe the same) extensions as the Hitachi 6309 https://en.wikipedia.org/wiki/Hitachi_6309 https://en.wikipedia.org/wiki/Hitachi_6309 That is, it has a 32-bit accumulator (made up of four 8-bit accumulators) but apparently no address extensions.

bjconlan 2y ago
Wow I didn't know Hitachi made anything outside of their superh/sh CPUs (which also do a mixed encoding scheme) I'm guessing they derived it from these guys and appeased the risc crowds. Off topic but I wonder what ever happened to that j-core project. I have a feeling understanding/learning both the turbo9/6809 along with the j2/sh2 would make for a great comparison.