Difference between revisions of "Gadget:Gen-X"
Jump to navigation
Jump to search
m |
|||
| (10 intermediate revisions by the same user not shown) | |||
| Line 7: | Line 7: | ||
* On hard-reset, the FPGA copies the first 64k of flash to $0. | * On hard-reset, the FPGA copies the first 64k of flash to $0. | ||
* Post-upload reset leaves that block alone, so you can upload code there. | * Post-upload reset leaves that block alone, so you can upload code there. | ||
| + | * Remember that the 68040 has THREE stacks: user, supervisor, and interrupt. Reset puts you on the interrupt stack. | ||
Documentation | Documentation | ||
| Line 16: | Line 17: | ||
* MOVE16 presently only works with the SRAM in the first 4MB. | * MOVE16 presently only works with the SRAM in the first 4MB. | ||
| + | ** Confirmed ... can't burst from flash either. | ||
** This basically means you can't cache anything anywhere else. | ** This basically means you can't cache anything anywhere else. | ||
| − | ** | + | ** Ugh. Burst writes don't seem to be reliable (they appear to be getting out of sync); burst reads appear to be working. |
| + | ** Then again, this may have been temperature dependent. I haven't seen it since plugging in the fan and leaving it running. | ||
* Stef says to avoid using the DRAM for now. | * Stef says to avoid using the DRAM for now. | ||
| + | * Because the MMU makes all of its fetches using burst mode, for now, its tables must be in SRAM. | ||
| + | * The MMU will not dcache table entries, but it can lock up if tables none-the-less end up there. Motorola recommends avoiding this scenario by disabling caching on MMU table memory. If this is not possible (as presently on the Foenix), they recommend disabling either the MMU or the dcache during table updates. | ||
| + | ** IMHO, an easy solution here (so long as you're only using the MMU for access control) is to hard-code the tables after the vectors and otherwise avoid touching them. If you /do/ need to touch them, statically alias them somewhere else in memory, and mark that region no-cache. | ||
I/O (68k) | I/O (68k) | ||
* Power and SD Card LED control bits at GAVIN:0000 (feca) don't appear to work. | * Power and SD Card LED control bits at GAVIN:0000 (feca) don't appear to work. | ||
| − | * | + | * LFSR registers must be accessed in 32 bit mode. |
* The I/O space should be marked as serialized/no-cache (defaults to unserialized -- reads can get ahead of writes). | * The I/O space should be marked as serialized/no-cache (defaults to unserialized -- reads can get ahead of writes). | ||
| Line 29: | Line 35: | ||
* The 68040 MOVEC cache and MMU control registers are there, but typically without the last letter (R for Register). | * The 68040 MOVEC cache and MMU control registers are there, but typically without the last letter (R for Register). | ||
| + | * Auto-alignment rules are brain-damaged: the assembler will re-align instructions but not their associated labels, and won't even warn you if constants are mis-aligned. | ||
| + | ** Ha! The -align option forces natural alignment of data. This fixes most of the problems. Just be sure to manually re-align after any byte data. | ||
Latest revision as of 22:53, 3 July 2023
Getting Started
- Both displays show logos, but only display B is responsive.
Startup
- On hard-reset, the FPGA copies the first 64k of flash to $0.
- Post-upload reset leaves that block alone, so you can upload code there.
- Remember that the 68040 has THREE stacks: user, supervisor, and interrupt. Reset puts you on the interrupt stack.
Documentation
- The Gen-X on the 68k side appears to be an A2560K; preliminary documentation is Here.
- The Gen-X on the 65816 side appears to be an FMX.
Memory
- MOVE16 presently only works with the SRAM in the first 4MB.
- Confirmed ... can't burst from flash either.
- This basically means you can't cache anything anywhere else.
- Ugh. Burst writes don't seem to be reliable (they appear to be getting out of sync); burst reads appear to be working.
- Then again, this may have been temperature dependent. I haven't seen it since plugging in the fan and leaving it running.
- Stef says to avoid using the DRAM for now.
- Because the MMU makes all of its fetches using burst mode, for now, its tables must be in SRAM.
- The MMU will not dcache table entries, but it can lock up if tables none-the-less end up there. Motorola recommends avoiding this scenario by disabling caching on MMU table memory. If this is not possible (as presently on the Foenix), they recommend disabling either the MMU or the dcache during table updates.
- IMHO, an easy solution here (so long as you're only using the MMU for access control) is to hard-code the tables after the vectors and otherwise avoid touching them. If you /do/ need to touch them, statically alias them somewhere else in memory, and mark that region no-cache.
I/O (68k)
- Power and SD Card LED control bits at GAVIN:0000 (feca) don't appear to work.
- LFSR registers must be accessed in 32 bit mode.
- The I/O space should be marked as serialized/no-cache (defaults to unserialized -- reads can get ahead of writes).
vasm
- The 68040 MOVEC cache and MMU control registers are there, but typically without the last letter (R for Register).
- Auto-alignment rules are brain-damaged: the assembler will re-align instructions but not their associated labels, and won't even warn you if constants are mis-aligned.
- Ha! The -align option forces natural alignment of data. This fixes most of the problems. Just be sure to manually re-align after any byte data.
