Does MC68SEC000 have a working bus error recovery? - Page 1
Forum section: electronics / general

author: technix
author_rank: Super Contributor
timestamp: October 09, 2018, 07:21:21 am
content: As far as we know the bus error recovery of MC68HC000 is bugged preventing implementation of MMU, while the 68010 fixed that. Does the DragonBall-derived MC68SEC000 have the bugged bus error recovery then? Being a newer core it should have that fixed bus error recovery, on the other hand it still carries the 68xx000 name...

author: Benta
author_rank: Super Contributor
timestamp: October 09, 2018, 08:56:28 am
content: It's not a bug, it's a featureYou are probably talking about the 68000 "instruction reexecute on bus error" vs. the 68010 "instruction execution continue on bus error". This allows the 68010 to operate with virtual memory.All 68000 including the 68SEC000 do not support virtual memory, you'll have to go up to the 68020 to implement that.

author: technix
author_rank: Super Contributor
timestamp: October 09, 2018, 10:16:17 am
content: Quote from: Benta on October 09, 2018, 08:56:28 amWell there dashed the hope of a MMU...I do still need some kind of memory remapping so I can boot with NOR at address 0 and run with RAM at address 0, so maybe 2MB segments? I only have a little over 6MB defined physical address space (4MB SRAM, 2MB NOR Flash, and some 256-byte-aligned peripherals)

author: Benta
author_rank: Super Contributor
timestamp: October 09, 2018, 12:31:29 pm
content: You could consider moving to one the CPU32-based integrated controllers. Fully upward compatible to 68000 and they support virtual memory.MC68332, for example.Or a ColdFire processor, also 68k compatible.

author: glarsson
author_rank: Frequent Contributor
timestamp: October 09, 2018, 12:44:42 pm
content: Quote from: technix on October 09, 2018, 10:16:17 amHistorically you implemented support for MMU using a second 68000 running a half step behind or generating stack probes in the compiler code generator. I still have a 68008-based system with MMU using stack probes.A stack probe was an instruction that accessed memory that might not be mapped. If it failed you had a page fault but you didn't need to restart the instruction as its sole purpose was to provoke a page fault. Probably not used any more?

author: technix
author_rank: Super Contributor
timestamp: October 09, 2018, 12:56:31 pm
content: Quote from: Benta on October 09, 2018, 12:31:29 pmIf I go that new on the processors I personally would prefer things like Intel 80386EX or AT91SAM9260 - built-in MMU and various peripherals. 80386EX + SeaBIOS ca run Linux 2.6, AT91SAM9260 is supported in latest mainline Linux and Debian.I will look into 68332 though.Quote from: glarsson on October 09, 2018, 12:44:42 pmI wonder if modern compiler still have that code generation switch...

author: Benta
author_rank: Super Contributor
timestamp: October 09, 2018, 01:00:57 pm
content: 80387? Isn't that a floating-point coprocessor?

author: technix
author_rank: Super Contributor
timestamp: October 09, 2018, 01:14:59 pm
content: Quote from: Benta on October 09, 2018, 01:00:57 pmTypo. Should be 80386EX.

author: mfro
author_rank: Regular Contributor
timestamp: November 06, 2018, 08:29:05 am
content: Quote from: technix on October 09, 2018, 10:16:17 amCheck out Motorola App. Note 897. They basically just count the number of cycles (using AS) since reset and make sure ROM is mapped to 0 during the first eight. No need for an MMU.

author: technix
author_rank: Super Contributor
timestamp: November 06, 2018, 08:44:24 am
content: Quote from: mfro on November 06, 2018, 08:29:05 amThanks for that, and I think such a cycle counter should be easily implementable in a XC2C64A address decoder.I have bought some new old stock Micron 4MB (2M x16) PSRAM. It would be cray if a 68SEC000 box has 12MB RAM. (12MB PSRAM, 2MB NOR Flash, 2MB I/O space for Ethernet, USB and touchscreen.)